Friday Aug 02, 2013

Securing WebSocket applications on Glassfish

Today we are going to cover deploying secured WebSocket applications on Glassfish and access to these services using WebSocket Client API.

WebSocket server application setup

Our server endpoint might look as simple as this:

public class EchoEndpoint {

  public String echo(String message) {
    return message + " (from your server)";

Everything else must be configured on container level.

We can start with enabling SSL, which will require web.xml to be added to your project. For starters, it might look as following:

<web-app version="3.0" xmlns="">
      <web-resource-name>Protected resource</web-resource-name>

    <!-- https -->

This is minimal web.xml for this task - web-resource-collection just defines URL pattern and HTTP method(s) we want to put a constraint on and user-data-constraint defines that constraint, which is in our case transport-guarantee. More information about these properties and security settings for web application can be found in Oracle Java EE 7 Tutorial.

I have some simple webpage attached as well, so I can test my endpoint right away. You can find it (along with complete project) in Tyrus workspace: [webpage] [whole project].

After deploying this application to Glassfish Application Server, you should be able to hit it using your favorite browser. URL where my application resides is https://localhost:8181/sample-echo-https/ (may be different, depends on other configuration). My browser warns me about untrusted certificate (I use what freshly built Glassfish provides - self signed certificates) and after adding an exception for this site, I can see my webpage and I am able to securely connect to wss://localhost:8181/sample-echo-https/echo.

WebSocket client

Already mentioned demo application also contains test client, but execution of this is skipped for normal build. Reason for this is that Glassfish uses these self-signed "random" untrusted certificates and you are (in most cases) not able to connect to these services without any additional settings.

Creating test WebSocket client is actually quite similar to server side, only difference is that you have to somewhere create client container and invoke connect with some additional info. Java API for WebSocket allows you to use annotated and programmatic way to construct endpoints. Server side shows the annotated case, so let's see how the programmatic approach will look.

final WebSocketContainer client = ContainerProvider.getWebSocketContainer();
client.connectToServer(new Endpoint() {
  public void onOpen(Session session, EndpointConfig EndpointConfig) {
    try {
      // register message handler - will just print out the
      // received message on standard output.
      session.addMessageHandler(new MessageHandler.Whole<String>() {
        public void onMessage(String message) {
          System.out.println("### Received: " + message);

      // send a message
      session.getBasicRemote().sendText("Do or do not, there is no try.");
    } catch (IOException e) {
      // do nothing
}, ClientEndpointConfig.Builder.create().build(),

This client should work with some secured endpoint with valid certificated signed by some trusted certificate authority (you can try that with wss:// Accessing our Glassfish instance will require some additional settings. You can tell Java which certificated you trust by adding property (and few others in case you are using linked sample).

Complete command line when you are testing your service might need to look somewhat like:

mvn clean test$AS_MAIN/domains/domain1/config/cacerts.jks\\

Where AS_MAIN points to your Glassfish instance.

Note: you might need to setup keyStore and trustStore per client instead of per JVM; there is a way how to do it, but it is Tyrus proprietary feature:

And that's it! Now nobody is able to "hear" what you are sending to or receiving from your WebSocket endpoint.

There is always room for improvement, so the next step you might want to take is introduce some authentication mechanism (like HTTP Basic or Digest). This topic is more about container configuration so I'm not going to go into details, but there is one thing worth mentioning: to access services which require authorization, you might need to put this additional information to HTTP headers of first (Upgrade) request (there is not (yet) any direct support even for these fundamental mechanisms, user need to register Configurator and add headers in beforeRequest method invocation). I filed related feature request as TYRUS-228; feel free to comment/vote if you need this functionality.

Wednesday Jul 31, 2013

Tyrus on GitHub - continued

Tyrus now uses GIT as primary source code repository, old SVN repository will stay online, but won't be updated.

Main benefit here is that we have active GitHub mirror and we are able to use all of its features, so users can fork Tyrus "trunk" (master branch) or tags (released versions), make changes and create pull requests. We plan to use pull requests for our code reviews as well, so feel free to comment some changes or suggest improvements. Please note that Oracle Contributor Agreement is still requirement for accepting any pull request.

See for further info.

Friday Jul 26, 2013

Tyrus 1.2

UPDATE - Tyrus 1.2.1

Tyrus 1.2.1 contains fix for TYRUS-222

Original post about Tyrus 1.2

Another release cycle is finished which allows me to present Tyrus in version 1.2. This version brings some bugfixes and features, for example improved Servlet integration, correct ByteBuffer handling when sending messages, improved client-side SSL ("wss://...") support and important fixed for handling of huge messages (client and server side).

As previously - I will follow with more blog posts about selected features later. Some of them are already described in updated User guide.

Complete list of bugfixes and new features


(You might see some of these as still open, but that's due to some issues with JIRA which should be hopefully fixed soon).

Tyrus 1.2 is already integrated in Glassfish trunk – you can download nightly build or upgrade to newer Tyrus manually (replace all Tyrus jars).

Related links:

Tuesday Jul 16, 2013

WebSocket via HTTP proxy

As you might know, WebSocket can be used for bi-directional "real-time" communication with multiple clients. What does that mean in proxy environments and how this even works? WebSocket uses HTTP upgrade mechanism specified in HTTP 1.1 and by design requires open (TCP) connection.

HTTP CONNECT is there for exactly these usecases. It is usually used for tunneling HTTPS via proxy, but it can be used for WebSocket as well.

I will describe complete "proxified" handshake using captured connection of Tyrus Client connecting to public echo service - Please note that we are directly using Tyrus API - not WebSocket specification (JSR-356), because we need to set a proxy.

final ClientManager client = ClientManager.createClient();

  GrizzlyClientSocket.PROXY_URI, "http://my.proxy:8080"
final Session session = client.connectToServer(new Endpoint() {

  public void onOpen(Session session, EndpointConfig config) {
    session.addMessageHandler(new MessageHandler.Whole<String>() {
      public void onMessage(String message) {
        System.out.println("# Message received: " + message);
}, ClientEndpointConfig.Builder.create().build(),

session.getBasicRemote().sendText("test message");

BTW, Tyrus Client proxy support can be improved, currently it does not support proxy authentication, JDK's ProxySelector and so on. Please vote/comment on TYRUS-204 if you lack some of the mentioned options or anything else related to proxy support.

Current modern browsers do support this out of the box, so all you need is to set your HTTP proxy and described handshake will be done automatically. There might be limitation for parallel open connection in browser tab/instance, but I don't have any exact data about this.

Also, you might ask whether there is some need to server-side support - simple answer is "no". HTTP containers will see regular connection (from proxy), there is no additional work or overhead on that side.

Lets see our dumped communication:

client > proxy
Proxy-Connection: keep-alive
Connection: keep-alive

Firstly, client need to send a request to proxy for new "permanent" connection. As already mentioned, CONNECT method handles this. First argument is a hostname ( and standard HTTP version.

proxy > client
HTTP/1.0 200 Connection established

If you are lucky, your proxy does support CONNECT and allows you to create connection (HTTP 200 is returned).

client > proxy
GET / HTTP/1.1
Connection: Upgrade
Sec-WebSocket-Key : sDD3Wk7PMRCPE9+C0VyOcQ==
Sec-WebSocket-Version: 13
Upgrade: websocket

This is standard WebSocket handshake request, which will be passed to target HTTP container.

proxy > client
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 8TNIHr7bJHqQadjXYvqLql6RFEA=
Date: Tue, 16 Jul 2013 15:30:53 GMT

And there is a valid response to our handshake request, connection is established and communication can be started; there is nothing else different than in proxy-less environment. Please note that proxies do have limited resources and your request may be turned down because proxy "CONNECT" pool is empty.

Conclusion here is that WebSocket can work via proxies without any limitation, it just introduces different kind of traffic than pure HTTP and might cause some additional requirements related to proxy performance in case you are going to use WebSocket for long-running client connections.

Wednesday Jul 10, 2013

Tyrus on GitHub

Tyrus is now being mirrored to github. Pull requests currently cannot be accepted (one-way sync for now), but that will be improved over time. (Contributors are still required to provide patch, see


Monday Jul 08, 2013

WebSocket command line client

Tyrus 1.1 brings new feature - simple command line client, which can be useful in many scenarios. You can use it for simple development testing, sanity testing or for monitoring of your deployed endpoints.

How to use:

# you can use wget .. or anything else you like:
wget -O ./tyrus-client-cli-1.1.jar
  • Execute downloaded binary
java -jar ./tyrus-client-cli-1.1.jar --help

that should print out usage information. Tyrus CLI client currently supports sending text messages and pings to one opened endpoint + you can close current session and connect to another one within one run. (If you try to open another connection while having another one already connected, close will be invoked automatically, so you will be still talking only to one endpoint).


$ java -jar ./tyrus-client-cli-1.1.jar ws://
# Connecting to ws://
# Connected in session e303ad22-c5af-4bc3-9384-58ce6832ae94
session e303...ae94> ping
# pong-message
session e303...ae94> send tyrus-test-message
# text-message: tyrus-test-message
session e303...ae94> close
# closed: CloseReason[1000,no reason given]
# Session closed

note: lines starting with hash '#' symbol are generated from the client runtime, "# text-message: ..." means text message was received, etc.

This utility can be improved, please let us know if you have any suggestions about what feature would you like to add.

Many thanks to Gerard Davison for contributing main functionality of this module!

Tuesday Jul 02, 2013

Tyrus 1.1

It might seem like there is not much time passed since Tyrus 1.0 (Java API for WebSocket reference implementation) release, but the fact is it was frozen several weeks before going public and development in the trunk continued. Tyrus 1.1 brings some new features and improvements:

  • client-side proxy support
  • simple command line client
  • various stability/performance fixes (see below for complete list)

Individual blog posts about highlighted features will follow, same as related user guide chapters.. stay tuned!

Tyrus 1.1 is already integrated in Glassfish trunk - you can download nightly build or upgrade to newer Tyrus manually (replace all Tyrus jars; I know this is not very user friendly, so I'll try to come up with some better solution or at least simple guide).

Complete list of bugfixes/improvements:

Related links:

Wednesday Jun 19, 2013

Tyrus 1.0

Hi all,

Java EE 7 was released last week and lots of new exciting libraries and frameworks with it. One of them is Tyrus 1.0, reference implementation of JSR-356: Java API for WebSocket.

Tyrus has new home page (thanks to whole Grizzly team to allow us use their web as a base for ours), user guide and much more. Please check it out on and let us know what you think on We are always open for any suggestions or requests (features, tutorials, documentation, ...)!

Tyrus project has bigger ambition than just be reference implementation, so stay tuned, some cool features are planned (and already done) for Tyrus 1.1 release. If you have anything you would want to get into it, please file a bug/improvement on our issue tracker.


Friday Jun 07, 2013

Tyrus 1.0 user guide

We published first version of Tyrus user guide (thanks Stepan!) and we are looking for any feedback. I'm pretty sure current version would be sufficient for most of usecases, but there is always room for improvements.

 User guide:

Feel free to drop us a note about anything you'd expect to find there to Thanks!

Tuesday Apr 02, 2013

Tyrus 1.0-rc1 released

Glassfish HCF is almost here, so is another Tyrus release. This one should be feature complete – that means all features and usecases described in the WebSocket specification (JSR 356) should work. We’ll see how many bugs will be raised after release..

Anyway, new WebSocket API (1.0-rc3) was released in the meantime, so there are some changes which might affect existing applications written using Tyrus/WebSocket API.

So let’s start:

  • ServerContainerProvider is gone.
  • ServerEndpointConfig.Configurator#matchesURI is gone
  • Encoder/Decoder.Adapter is gone.

And that’s basically it. There are additional changes in the spec document, mostly related to wording and some corner cases, but there is one thing which I want to point out – WebSocket spec 1.o-rc3 introduces path matching algorithm. See the spec itself for detailed description, but short summary would be: we got rid of customizable URI matching and replaced it with “standard” one, which still allows path templates and solves issue with multiple templates matching to same path. Additionally, RI (Tyrus) should not allow to deploy two endpoints with exactly same path templates (in terms of parsed state, so.. “/foo/bar” and “/foo/{bar}” are different, but “/foo/{bar}” and “/foo/{baz}” are the same).

Tyrus already implements it, so you can checkout latest Glassfish and try it out or wait for b83.

Other changes in Tyrus itself were mainly about getting done spec features and some bugfixing (of course). Latest and more interrestion additions are session timeouts and buffer size implementations. Also we managed to resolve threading issues on linux, so if you have experienced them, please try recent Glassfish and let us know if you still see any issue.

I hope that covers all bigger changes, but this post is not supposed to be complete list; if you want to see them all, please check API javadoc and spec document. And as always, you can always ask us! Tyrus (implementation): ; API:

Saturday Mar 09, 2013

Tyrus 1.0-b13 released

Tyrus 1.0-b13 is out and it brings new WebSocket API 1.0-rc1, which contains some bigger renames and additions, like the last time. Since it is going to affect almost all code written using previous API, I'll again try to summarize changes to make transition as easy as possible.


Original New
EndpointConfiguration EndpointConfig
ServerEndpointConfiguration ServerEndpointConfig
ClientEndpointConfiguration ClientEndpointConfig
ServerEndpointConfigurator ServerEndpointConfig.Configurator
ClientEndpointConfigurator ClientEndpointConfig.Configurator
ServerApplicationConfiguration ServerApplicationConfig
ServerEndpointConfigurationBuilder ServerEndpointConfig.Builder
ClientEndpointConfigurationBuilder ClientEndpointConfig.Builder
MessageHandler.Basic MessageHandler.Whole
MessageHandler.Async MessageHandler.Partial

New Features

Encoder and Decoder interface got two new methods - init(EndpointConfig) and destroy(). As you most likely guessed out already, init is called when Encoder/Decoder is initiated and destroy when it is going to be destroyed or no longer used. Lifecycle of these objects changed from singleton to per session. Additionally Encoder.Adapter and Decoder.Adapter were added with empty impl of mentioned methods to ease implementing custom coders which do not rely on newly added methods.

ServerContainer and ServerContainerProvider have been introduced, but there is still open discussion about functionality they should provide, so some changes might happen here. ServerContainer allows users to "dynamically" add some endpoints during deployment, but its functionality is limited only to Servlet deployment phase. See javadoc for more information or check out test on Tyrus workspace - tests/servlet/dynamic-deploy or download from maven central - dynamic-deploy sample.

WebSocketContainer connectToServer(...) methods which take endpoint instance are back, enjoy ;)

EndpointConfig now has getters for sets of Encoder/Decoder classes instead of instances (it relies to scope change mentioned in 3 paragraphs above). It also nicely matches annotated case (see @ServerEndpoint and @ClientEndpoint).

ServerEndpointConfig.Configurator (used to be ServerEndpointConfigurator) has one new method getEndpointInstance(Class<T> clazz), which can be overridden and will be used to create new instances of all endpoints. So you can easily influence scoping of created instances. But beware, you won't be able to do anything more granular than one endpoint instance per session. Container provided implementation should support EJB and CDI, check out our CDI sample.

I hope that covers all bigger changes, other things are minor modifications mostly, like changing thrown exceptions etc. This short post is not supposed to be complete list of changes, if you want to see them all, please check API is javadoc and spec document: . And as always, you can always ask us! Tyrus (implementation): ; API:

Wednesday Feb 27, 2013

Tyrus 1.0-b12 released

This release implements new version of WebSocket API which introduces major renames and even some changes in the way how you can configure advanced behavior. Unfortunately, this will make all related applications written using Tyrus uncompilable and already compiled ones undeployable (when integrated to Glassfish).

I'm sure we will receive lots of bugs relates to this change, but all I can do is try to prevent is somehow - for example by writing list of changes which you are reading right now :).

Important renames

Original name Current name
@WebSocketEndpoint @ServerEndpoint
@WebSocketClient @ClientEndpoint
@WebSocketOpen @OnOpen
@WebSocketMessage @OnMessage
@WebSocketPathParam @PathParam
@WebSocketClose @OnClose
@WebSocketError @OnError

There were no changes in packaging, so javax.websocket or javax.websocket.server is still valid.

Other changes

Another set of changes is related to Endpoint configuration. ServerEndpointConfiguration and ClientEndpointConfiguration is still there, but default implementations are gone (package private); users are supposed to use ServerEndpointConfiguraiontBuilder and ClientEndpointConfigurationBuilder in order to create new configuration instance. This change is not yet complete, so prepare for another renaming (Configuration will be Config).

Last but not least is separating user implementation from Configuration to Configurator. There are two of them, Server and Client side and they take care of calls like "matchURI", "modifyHandshake", "beforeRequest", "afterResponse". Usually you don't really need to call them, so API/RI providers default implemetation, but you might find these useful in some advanced cases, like implementing your own totally cool and unheard path matching algorithm. This class will also be renamed in next release (to something like ServerEndpointConfig.Configurator), but functionality should stay very similar (if not exactly the same).

Additionall, @ServerEndpoint and @ClientEndpoint now do NOT have configuration parameter. Everything from EndpointConfiguration should be configurable as annotation parameters plus you can set Configurator here for some more advanced usecases.

Deployment has been also altered. ServerApplicationConfiguration now deploys annotated classes or ServerEndpointConfiguration INSTANCES. Newly introduced method "getEndpointConfigurations" takes set of scanned Endpoint descendants and its up to implementor which of them will be included in returned set. Endpoint descendant needs some more info about the deployment (path, encoders, decoders, ...), so ServerEndpointConfiguration has to be created. Please note that any "loadable" endpoint can be returned (scanned classes may be ignored).

Session interface also received some refactorings, "getRemote()" dissapeared and was replaced by "getBasicRemote()" and "getAsyncRemote()". You can guess what can you do with them. On a related note - RemoteEndpoint is no longer usable on its own, it just provides common base for RemoteEndpoint.Basic and RemoteEndpoint.Async. Methods related to sending messages were also renamed, sendString is now sendTest, sendBytes is now sendBinary and these names are used for partial messages as well (only difference is now different parameters).

Let's get to the code part:

Plain echo endpoint:

public class PlainEcho {

    public String onMessage(String s) {
        return s;


    @ServerEndpoint(value = "/echo", configurator = MyServerConfigurator.class)
    public static class TestEndpoint {

        public String onMessage(String message) {
            return message;

    public static class MyServerConfigurator extends ServerEndpointConfigurator {

        public void modifyHandshake(ServerEndpointConfiguration sec,
                                    HandshakeRequest request,
                                    HandshakeResponse response) {
            final List<String> list = request.getHeaders().get(HEADER_NAME);
            response.getHeaders().put(HEADER_NAME, list);

ServerApplicationConfiguration programmatic deployment:

    public static class MyAppConfig implements ServerApplicationConfiguration {

        public Set<ServerEndpointConfiguration> getEndpointConfigurations(Set<Class<? extends Endpoint>> endpointClasses) {
            return new HashSet<ServerEndpointConfiguration>() {{
                add(ServerEndpointConfigurationBuilder.create(MyEndpoint.class, "/myEndpoint").build());


        public Set<Class<?>> getAnnotatedEndpointClasses(Set<Class<?>> scanned) {
            return null;


    public void onOpen(Session session) throws IOException {
        final Future<Void> future = session.getAsyncRemote().sendText("myText");

I'm sure I did not covered all changes (things are still moving forward); best source for info about API is javadoc and spec document: . And as always, you can always ask us! Tyrus (implementation): ; API:

Friday Jan 18, 2013

Tyrus 1.0-b09 released

I've started working on new project - Reference Implementation of JSR 356: Java API for WebSocket - Tyrus and we just released new version.

What is Tyrus?

Tyrus providers implementation for JSR 356 plus some other (currently minor) improvements. Project itself is still in development phase, so you probably don't want to use it in production environment - especially when specification itself is not yet final - but if you want to be on track with this project, this is the release you want to use. We have worked hard to get implementation to support most of JSR-356 features and hopefully all core functionality.

Our implementation passes most of Autobahn testsuite (there are some Servlet 3.1 related issues but also in our implementation, I don't want to blame only Servlet folks ;) ). We should sort that out in next release cycle.

How can I try it?

Best way would be with fresh Glassfish, which should contain Tyrus 1.0-b09 (it is not available yet, but should be later today; link). Then you can build Echo sample from Tyrus samples directory and start exploring WebSockets and create simple game or other application which can take advantage of bi-directional communication provided by WebSocket protocol.

How to run Echo sample:

if you really want just quick peek, you can download Tyrus echo sample war file, deploy it and hit deployed application from your browser. But its just "hello world" type app, you most likely want to modify source and play with it. So you'll end up with checking out sources anyway :)

svn co
cd echo
mvn clean install

Build war file is present in target directory. Please note you might need to disable tests if you are changing functionality (add -Dmaven.test.skip when building sample).

If you want more information, check out Public Review draft (spec api version 1.0-b11), and Tyrus home page.

As usual, if you find some issues/bugs, feel free to file them on our JIRA or send us a note to mailing list. Any questions about implementation are also welcomed, so if you are stuck at some point when implementing Tyrus based application, don't hesitated and let us know - we should be able to help you.

useful links:

latest Glassfish:
Tyrus homepage:
JSR-356 homepage:

Wednesday Jul 13, 2011

Jersey - Automatic XML schema generation for WADL

Gerard Davison contributed to Jersey one (last!) thing which is needed for generating client based on returned wadl - he managed to add XML schemas which describe returned (or accepted) types. See more details in his blog post: Auttomatic XML Schema generation for Jersey WADLs.

Thanks Gerard! ..and looking forward to another contribution(s) :-)

Monday Jul 11, 2011

Jersey - Server and Client side configuration

Originaly this was supposed to be something what are we lacking in our user guide - list of all init params plus at least one sample to each one.. but I wasn't able to finish it yet (and its on my TODO list for at least six months :-| ). But I think just a list with links to javadoc should be useful as well. Please note that this is not complete list and it might be (but I don't guarantee anything) updated in time. Reason why I did this is to sum up all possible properties - it is usable even for me (as a developer) because I can't remember everything :-) And I guess that this list will be sometimes included in Jersey user guide.

Server side init params

field (declaration) value
FeaturesAndProperties FEATURE_DISABLE_XML_SECURITY "com.sun.jersey.config.feature.DisableXmlSecurity"
FeaturesAndProperties FEATURE_FORMATTED "com.sun.jersey.config.feature.Formatted"
FeaturesAndProperties FEATURE_XMLROOTELEMENT_PROCESSING "com.sun.jersey.config.feature.XmlRootElementProcessing"
FeaturesAndProperties FEATURE_PRE_1_4_PROVIDER_PRECEDENCE "com.sun.jersey.config.feature.Pre14ProviderPrecedence"
JSONMarshaller FORMATTED "com.sun.jersey.api.json.JSONMarshaller.formatted"
LoggingFilter FEATURE_LOGGING_DISABLE_ENTITY "com.sun.jersey.config.feature.logging.DisableEntitylogging"
ClassNamesResourceConfig PROPERTY_CLASSNAMES ""
ClasspathResourceConfig PROPERTY_CLASSPATH ""
PackagesResourceConfig PROPERTY_PACKAGES ""
ResourceConfig FEATURE_NORMALIZE_URI "com.sun.jersey.config.feature.NormalizeURI"
ResourceConfig FEATURE_CANONICALIZE_URI_PATH "com.sun.jersey.config.feature.CanonicalizeURIPath"
ResourceConfig FEATURE_REDIRECT "com.sun.jersey.config.feature.Redirect"
ResourceConfig FEATURE_MATCH_MATRIX_PARAMS "com.sun.jersey.config.feature.IgnoreMatrixParams"
ResourceConfig FEATURE_IMPLICIT_VIEWABLES "com.sun.jersey.config.feature.ImplicitViewables"
ResourceConfig FEATURE_DISABLE_WADL "com.sun.jersey.config.feature.DisableWADL"
ResourceConfig FEATURE_TRACE "com.sun.jersey.config.feature.Trace"
ResourceConfig FEATURE_TRACE_PER_REQUEST "com.sun.jersey.config.feature.TracePerRequest"
ResourceConfig PROPERTY_DEFAULT_RESOURCE_COMPONENT _PROVIDER_FACTORY_CLASS " DefaultResourceComponentProviderFactoryClass"
ResourceConfig PROPERTY_CONTAINER_NOTIFIER "com.sun.jersey.spi.container.ContainerNotifier"
ResourceConfig PROPERTY_CONTAINER_REQUEST_FILTERS "com.sun.jersey.spi.container.ContainerRequestFilters"
ResourceConfig PROPERTY_CONTAINER_RESPONSE_FILTERS "com.sun.jersey.spi.container.ContainerResponseFilters"
ResourceConfig PROPERTY_RESOURCE_FILTER_FACTORIES "com.sun.jersey.spi.container.ResourceFilters"
ServletContainer GLASSFISH_DEFAULT_ERROR_PAGE_RESPONSE "org.glassfish.web.isDefaultErrorPageEnabled"
ServletContainer FEATURE_FILTER_FORWARD_ON_404 "com.sun.jersey.config.feature.FilterForwardOn404"
ServletContainer PROPERTY_FILTER_CONTEXT_PATH "com.sun.jersey.config.feature.FilterContextPath"

Client side init params

field (declaration) value
ClientConfig PROPERTY_BUFFER_RESPONSE_ ENTITY_ON_EXCEPTION " bufferResponseEntityOnException"
HTTPSProperties PROPERTY_HTTPS_PROPERTIES "com.sun.jersey.client.impl.urlconnection.httpsProperties"
URLConnectionClientHandler PROPERTY_HTTP_URL_CONNECTION _SET_METHOD_WORKAROUND " httpUrlConnectionSetMethodWorkaround"
ApacheHttpClientConfig PROPERTY_INTERACTIVE "com.sun.jersey.impl.client.httpclient.interactive"
ApacheHttpClientConfig PROPERTY_HANDLE_COOKIES "com.sun.jersey.impl.client.httpclient.handleCookies"
ApacheHttpClientConfig PROPERTY_CREDENTIALS_PROVIDER "com.sun.jersey.impl.client.httpclient.credentialsProvider"
ApacheHttpClientConfig PROPERTY_PREEMPTIVE_AUTHENTICATION "com.sun.jersey.impl.client.httpclient.preemptiveAuthentication"
ApacheHttpClientConfig PROPERTY_PROXY_URI "com.sun.jersey.impl.client.httpclient.proxyURI"
ApacheHttpClientConfig PROPERTY_HTTP_STATE "com.sun.jersey.impl.client.httpclient.httpState"
ApacheHttpClient4Config PROPERTY_DISABLE_COOKIES "com.sun.jersey.impl.client.httpclient.handleCookies"
ApacheHttpClient4Config PROPERTY_CREDENTIALS_PROVIDER "com.sun.jersey.impl.client.httpclient.credentialsProvider"
ApacheHttpClient4Config PROPERTY_PREEMPTIVE_ BASIC_AUTHENTICATION "com.sun.jersey.impl.client.httpclient. preemptiveBasicAuthentication"
ApacheHttpClient4Config PROPERTY_CONNECTION_MANAGER "com.sun.jersey.impl.client.httpclient.connectionManager"
ApacheHttpClient4Config PROPERTY_HTTP_PARAMS "com.sun.jersey.impl.client.httpclient.httpParams"
ApacheHttpClient4Config PROPERTY_PROXY_URI "com.sun.jersey.impl.client.httpclient.proxyURI"
ApacheHttpClient4Config PROPERTY_PROXY_USERNAME "com.sun.jersey.impl.client.httpclient.proxyUsername"
ApacheHttpClient4Config PROPERTY_PROXY_PASSWORD "com.sun.jersey.impl.client.httpclient.proxyPassword"

Pavel Bucek


« April 2014