Http1FieldPreEncoder not loaded/invalid array index in PreEncodedHttpField

[ghost]

I have run across an interesting scenario with Jetty Embedded in relation to HTTP/2.

What's happening

When I run my application with the GzipHandler enabled, I get an ExceptionInInitializerError, which comes from PreEncodedHttpField. The exception itself is the result of an ArrayIndexOutOfBoundsException thrown in PreEncodedHttpField line 70:

int i = index(e.getHttpVersion());
if (__encoders[i]==null)
    __encoders[i] = e;
else
    LOG.warn("multiple PreEncoders for "+e.getHttpVersion());

The reason for this exception is that in my case, only the HpackFieldPreEncoder encoder seems to be loaded, which is incorrectly placed on index 0 instead of index 1. The Http1FieldPreEncoder class is, for some reason, not loaded.

Reproducing

• OpenJDK 8

Jetty dependencies:

    compile group: 'org.eclipse.jetty', name: 'jetty-server', version: '9.4.1.v20170120'
    compile group: 'org.eclipse.jetty.http2', name:'http2-server', version:'9.4.1.v20170120'
    compile group: 'org.eclipse.jetty', name:'jetty-alpn-server', version:'9.4.1.v20170120'
    compile group: 'org.mortbay.jetty.alpn', name:'jetty-alpn-agent', version:'2.0.6'
    compile group: 'org.eclipse.jetty.alpn', name:'alpn-api', version:'1.1.3.v20160715'

Code:

GzipHandler gzip = new GzipHandler();

Suggested fix

In line 57, the index() function should be used to explicitly specify the index the encoder is inserted in:

if (index(encoder.getHttpVersion())>=0)
    //Missing explicit index here:
    encoders.add(encoder);

[ghost]

Update: I have narrowed the issue down to how my JAR file is packed. However, the code sample above contains a potential for a bug, so the indexing should still be fixed.

[hieplq]

if you use Osgi environment maybe it look like #262

[joakime]

Issue #705 has more information about OSGi + ServiceLoader + ClassLoaders

[sbordet]

@janoszen if you are repacking dependencies, you have to make sure that META-INF/services files are too repacked correctly.

Your fix would avoid the exception, but the exception itself is revealing of the underlying error, so it is better to fail fast rather than avoid the exception and have a non-working system.

If it's not OSGi or repacking, reopen the issue.