JpaTest failure when building kauri trunk on restlet trunk

[jgou]

The hudson job "KAURI_TRUNK_ON_RESTLET_TRUNK" fails since "restlet.org_4KAURI" build 160 on the JpaTest in the kauri-dbresources-impl module.

This regression is introduced by ​restlet r7646 .
To me it looks like a bug in the org.restlet.ext.json extension, so I reported it to the Restlet community in ​issue 1283 .

[jgou]

​restlet issue 1283 is fixed in ​restlet r7816

[mpo]

Reopening since the upgrade to recent restlet still hasn't happened in kauri.

Also noticed that since ​restlet 7852 another issue (see ​hudson log) is breaking the automated build.

I suggest to resolve both in one go now and upgrade to the current restlet. (​restlet r7904)

[mpo]

Things are more subtle then stated.

First new indication of the problem is seen in hudson ​log 219 which is indeed based on ​restlet 7852.
The run before that (shown in ​log 220 ) showed the JPA failure (original reason of this ticket) and was based on ​restlet 7846

So any of the restlet revisions between 7846 and 7852 could be the actual cause.

The resulting stacktrace might help us guide to the actual change that triggered the issue:

Exception intercepted while adding the response headers

java.lang.ClassCastException: org.restlet.data.Parameter
	at org.restlet.engine.header.HeaderUtils.addExtensionHeaders(HeaderUtils.java:218)
	at org.restlet.engine.header.HeaderUtils.addResponseHeaders(HeaderUtils.java:586)
	at org.restlet.engine.adapter.ServerAdapter.addResponseHeaders(ServerAdapter.java:89)
	at org.restlet.engine.adapter.ServerAdapter.commit(ServerAdapter.java:190)
	at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:150)
	at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167)
	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
	at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1048)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
	at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
	at java.lang.Thread.run(Thread.java:595)

[mpo]

CCE is caused by the fact that we still use Form in stead of Series<Header> to store response-headers. (At various places in the code, see RestServiceFacet.addModuleInfoHeader() RepresentationFilterFactory.getMedia())

Since the change described in ​restlet r7806 manipulation of the headers should update to the new type.

[mpo]

In [1932]:

upgrading to current restlet ​revision 7909
and making the necessary changes to our code base to comply

This change should get our ci-build happy again, and fixes #461

[mpo]

After pushing the maven jars of the selected restlet revision to the maven repo automated build is able to run properly

• ​http://ci.outerthought.org/job/KAURI_TRUNK/281/

Unfortunately though the original JPA error seems to re-surface now:

• ​http://ci.outerthought.org/job/KAURI_TRUNK_ON_RESTLET_TRUNK/230/

[mpo]

Update:

Build seems to now randomly fail on this or that test in our code-base (or even hapilly succeed).
Needs further investigation, but the hudson automated mail wording "build has become unstable" seems to describe the facts very adequately :(

See ​ci build 237 versus ​ci build 236 While there were no changes(!) the error is in a different test.

[mpo]

In [1934]:

bumping to latest restlet since latest trunk-builds seem more stable - see #461

[mpo]

In [1938]:

Getting to the bottom of the testRequests copy-pasted in various tests.
Replaces r1936 and r1937
Should finally get us the data hoped for @ci.outerthought.org
Also see #461