Implementing server extensions with Jersey

I've been working on an IssueProvider implementation to integrate our TeamCity 5.1.5 instance with our system for tracking UserStories.

The server provides a rest interface, so I thought that I might be able to to use Jersey to implement my client.

In my sandbox, everything works as I expect.

When bundled into a plugin, I start to have problems
com.sun.jersey.api.client.ClientHandlerException: A message body writer for Java type, class com.sun.jersey.api.representation.Form, and MIME media type, application/x-www-form-urlencoded, was not found

As best I can tell, what's happening here is that Jersey is defining a bunch of important readers in writers in jersey-core-1.1.4.jar/META-INF/services, and when run in the context of a teamcity server side plugin, these aren't getting picked up.

Has anybody managed to work around this problem?

2 comments
Comment actions Permalink

Danil,

While I have no solution to the issue you mentioned, here are some thoughts:
- I'd check that your sandbox solution and the one with plugin configure Jersey in exactly the same way.
- TeamCity comes bundled with REST API plugin that uses Jersey. You can use its sources for configuration ideas.
- Jersey can be peeky about classloaders and TeamCity plugins have something to do with classloaders too.
  1. I'd ensure that your plugin has teamcity-plugin.xml and there is a line in it: "<deployment use-separate-classloader="true"/>" This will make plugin to honor own classes more then those that might be provided by the server.
  2. Please see APIController.ensureInitialized methon in REST API plugin - you might need to do something similar to set context classloader before initializing Jersey.
- If nothing helps I'd turn to Jersey fine logging or debug to figure out what is wrong.

BTW, if your tracker is a public solution, please consider sharing your TeamCity plugin with other users.

0
Comment actions Permalink

Thanks Yegor,

I had looked at the teamcity-plugin.xml file for the rest-api, but not your actual implementation, for jersey configuration.  So if there is extra programmatic work to be done configuring Jersey to run in TeamCity, I didn't see it.

Ultimately, I ran out of development window, and rolled the Jersey implementation back out in favor of a raw HTTP client that was able to do the same thing.


I'll look into getting something published after we've had a chance to put this into production and shake the bugs out.

0

Please sign in to leave a comment.