The JSON-RPC 2.0 Client can now handle GZIP and DEFLATE compression

Does your JSON-RPC server return large amounts of data? If so applying HTTP response compression can greatly reduce network traffic and response time, occasionally by a whole magnitude if your JSON structures contain long repeating keys or values.

Today we released a new version of the JSON-RPC 2.0 Client library for Java that adds support for GZIP and DEFLATE compression. These two algorithms are commonly implemented by web servers such as Apache HTTPD and Apache Tomcat.

To enable HTTP response compression in your Java client app:

URL serverURL = new URL("");

JSONRPC2Session mySession = new JSONRPC2Session(serverURL);


The JSON-RPC client will then set the Accept-Encoding request header to signal that it can process compressed responses. Note that many web servers don’t have HTTP compression enabled by default so this setting will simply be ignored by them.

To enable compression in Apache Tomcat you need to configure the HTTP connector by setting compression to “on”.

The JSON-RPC client will then automatically decompress the HTTP responses before processing the JSON payload.

The new version of the JSON-RPC client library also improves HTTP cookie support. It has dropped the primitive internal cookie store in favour of the standard so now cookie expiration and replacement are also handled.

Opera finally with CORS support

Opera was the last major browser to add support for handling cross-origin requests in its 12th version. The CORS protocol was devised several years ago by a W3C working group to allow for clean making of cross-domain XHR, without JSONp hacks. CORS was initially adopted by Firefox and Chrome, and was subsequently joined by the other major players, such as Microsoft’s Internet Explorer.

Today more than 85% of the browsers on the web support CORS and an increasing number of developers are starting to use the protocol, judging by downloads of our CORS Filter package which allows CORS support to be easily retrofitted to any Java web app or service. When the new Opera 12 appeared the CORS Filter was successfully tested under it.

Thanks to Joost Cassee the CORS filter is now also available on Maven.

Access filters for JSON-RPC 2.0 services

Services on the web often have to be controlled for who and how accesses them. If they deal with sensitive data, such as usernames and passwords, you may want to ensure that all requests come in over encrypted HTTPS. If you’re running a private service, you may want to ensure that only selected internet hosts can make use of it. Or you may want to limit access to portions of the web API, such as administration, to selected users and clients.

For this purpose I created an Access Filter package for JSON-RPC 2.0 services. Today I released it to the public in its stable 1.1 version under a generous Apache 2.0 licence. I wanted filtering to be fast and robust, so the package was designed to be as simple and efficient as possible. It also nicely complements the proven Java libraries JSON-RPC 2.0 Base and JSON-RPC 2.0 Server.

The package defines four basic filters:

  • HostFilter Access filter ensuring JSON-RPC 2.0 requests originate from selected host names / IP addresses.
  • HTTPSFilter Access filter ensuring requests are passed over HTTPS.
  • X509ClientCertFilter Access filter ensuring HTTPS requests carry an X.509 client certificate with optional specified principal (subject DN).
  • APIKeyFilter Access filter ensuring clients present an API key for protected JSON-RPC 2.0 request methods.

There is a ready CompositeFitler which combines these four basic filters into a chain. You can then plug this filter chain into your JSON-RPC 2.0 service and call it prior to passing the incoming requests to the actual execution logic.

The CompositeFilter can be configured with a simple properties text file. The properties format is detailed in the JavaDocs for the CompositeFilterConfiguration class.

access.https.clientCertPrincipal=cn=John Doe,ou=people,cd=company,dc=org
access.apiKeys.exemptedMethods=ws.getName ws.getVersion ws.getTime sso.logout sso.getSession sso.proxiedLogout sso.getSession sso.sessionCount sso.listUsers

Alternatively, you may devise your own custom filter chain, based on the AccessFilterChain class.

How do you use the CompositeFitler?

// Parse config from properties, create composite filter
java.util.Properties props = ...
CompositeFilter filter = new CompositeFilter();
filter.init(new CompositeFilterConfiguration(props)); 

// Invoke the filter for each incoming JSON-RPC 2.0 request

// Parse JSON-RPC 2.0 request
JSONRPC2Request request = JSONRPC2Request.parse(...);

// Set the message context, i.e. client host IP, etc.
MessageContext mctx = new MessageContext(...);

// Call the filter
AccessFilterResult result = filter.filter(request, mctx);

if (result.accessAllowed()) {
    // Continue with request processing...

else {
    // Return specified access denied JSON-RPC 2.0 error
    // to the calling client
    JSONRPC2Error error = result.getAccessDeniedError().toJSONRPC2Error();

The Access Filter package is available at Bitbucket:

We plan to integrate into the upcoming new releases of the Json2Ldap, NimbusSSO and AuthService web services from NimbusDS software.

If you have comments of feedback to share, get in touch or leave a ticket at the Bitbucket repo.

New public repos

The open source projects led by Dzhuvinov Software can now be followed through their new public Git repos at Bitbucket.

For an overview of the Git repos go to

CORS Filter

CORS Filter is the first universal solution for fitting Cross-Origin Resource Sharing (CORS) support to Java web applications. CORS is a recent W3C effort to introduce a standard mechanism for enabling cross-domain requests in web browsers and participating servers.

Its Git repo is at

JSON-RPC 2.0 Base

Minimalist Java library for composing and parsing JSON-RPC 2.0 messages. No framework or transport layer dependencies. Batching left out for simplicity.

Its Git repo is at

JSON-RPC 2.0 Client

Minimal Java client-side library for dispatching requests and notifications to a JSON-RPC 2.0 server by means of HTTP(S) POST.

Its Git repo is at

JSON-RPC 2.0 Server

Simple server framework for processing JSON-RPC 2.0 requests and notifications.

Its Git repo is at

Pretty JSON

Pretty JSON formatter for Java.

Its Git repo is at

Java Property Utils

Typed retrieval of java.util.Properties as boolean, integer, floating point, string and enum values.

Its Git repo is at

JsWorld 2.7 with improved date/time parsing

JsWorld iconWith version 2.7 JsWorld received a small upgrade and a few small fixes to date, time and date/time parsing in JavaScript.

Case-insensitive parsing of dates

Weekday and months names, both in their full and abbreviated versions, are now parsed irrespective of case. This is done while taking care of world locales that don’t have the notion of case (quite many actually).

So, for example, if you have the en_GB locale and your date format pattern is set to

POSIX_LC.en_GB.d_fmt = "%d/%b/%Y"

then the following input will parse to the same date:

17/Apr/2010 -> 2010-04-17
17/apr/2012 -> 2012-04-17
17/APR/2012 -> 2012-04-17

Do write us when you wish to have such features added to JsWorld. This particular one was requested by a customer who wanted to have more flexible parsing of dates. I’m considering making the date/time parser even more flexible, while staying completely on the safe side.

Fixed bugs in %e, %k, %l parsing

JsWorld 2.7 also fixes a few bugs that may cause incorrect parsing of date/time values against format templates that use the %e (day of the month as a decimal number, space padded), %k (hour in 24-h clock as a decimal number) and the %l (hour in 12-h clock as a decimal number) patterns.

If you’re subscribed you should receive an email how to get this update shortly.

Browser-side JS numeric, currency and date/time formatting

JsWorld iconIt’s now four years since JsWorld‘s inception and today the JavaScript l10n library is used in a range of web applications, from international online retail to finance and enterprise SaaS.

What are the advantages of applying numeric, currency and date/time formatting on the browser-side?

1. Clean separation of data and presentation.

In the spirit of modern Ajax + Web 2.0 apps the web server can supply the raw numeric, currency or date/time values in raw JSON or HTML which the browser-side JavaScript then formats accoring to the current locale. You can then have your business logic focus on the raw data and services, while the front-end is taking care of the presentation.

Example of currency data supplied as JSON:

{ "amount":"1500000.99", "currency":"GBP", "locale":"en_GB" }

Which then JsWorld takes to format accordingly as British Pounds :


The data may alternatively be supplied as unformatted HTML elements which are then walked by a piece of JavaScript applying localised formatting according to their class (or some other attribute, e.g. “data-” in HTML5).

<span class="date">2012-01-09</span>

Which then if the current locale is set to Portuguese/Brazil (pt_BR) is converted to

9 de janeiro de 2012

JsWorld comes with a simple API which gives you plenty of flexibility in how the data is fed to the browser. It could arrive through JSON/XHR or XML or it could be static HTML.

2. Agile development

Now that you have clean separation between business data + logic and presentation layer your engineers can proceed with greater speed in developing and maintaining your applications. The back-end developers can concentrate on the data and the service process, your front-end developers on the user experience – without having to worry about intricacies of data l10n – this is JsWorld’s task.

3. Conserve server resources

The localisation of data, if done repeatedly or on large data sets, can consume quite a bit of CPU resources. If you do that in your PHP/Java servlet/Ruby/etc code on the server-side this will cost your own resources. So why not shift this load to the browser-side? The effects could be small or more significant, depending on your web app and the amount of traffic you serve.

JsWorld is now in its 2.5 release and supports over 300 languages, 200 countries and 100 currencies.

JsWorld 2.5 with updated locale definitions

JsWorld iconJust before going into the Christmas holidays we got out a new release of JsWorld, the most comprehensive JavaScript library for localised formatting and parsing of numbers, currency and date/times.

What is in the new release?

The locale definitions were updated to match the latest CLDR data from Unicode. JsWorld now supports 354 world locales, with some of them reflecting important recent changes, such as the new Indian Rupee sign which became official in 2011.

JsWorld 2.5 also fixes a bug which resulted in incorrect formatting of midnight time using AM/PM notation. Thanks to our customer who reported this problem.

The next locale updates are expected in the first half of 2012.

Merry Christmas to all of you 🙂

The God particle – a projected reality?

The Large Hadron Collider, image CERN

According to quantum theory observation affects reality. Could the God particle, the Higgs Boson, simply be projected reality?

One of the most astounding discoveries of quantum mechanics is that the very act of watching affects the observed reality. This was demonstrated in the minuscule world of waves and particles by a highly controlled experiment where electrons under observation change their “regular” wave-like behaviour to particle-like.

Today’s news are filled with reports from the latest experiments at CERN claiming that the God particle, the elusive Higgs boson, was finally proven to exist. Since ancient times people have strived to explain the universe. The so-called Standard Model theory is the modern take of scientists at that. A theory, however, must be proven experimentally in order to be accepted as true, and there a crucial missing piece for many years was the Higgs boson. And now that its existence is finally validated, scientists are one step closer to proving their theory of (almost) everything.

But wait a minute – if observation plays such a gigantic role in the subatomic world – what is then the likelihood of the detected traces of the Higgs particle simply being observer effects of the experiment and that mammoth machine behind it, the Large Hadron Collider? How much of these building blocks of matter is simply there because we’re looking for them?

Fantasy turned reality – ironically, this was the title of the Economist’s cover story on the God particle today 🙂