Resources linking in Dropwizard / JAX-RS 1.x (JSR 311) - java

I've got a problem with resources linking in Dropwizard. With JAX-RS 2.0 we've got magical javax.ws.rs.core.Link class which with it's builder can do almost all the work for you. Unfortunately Dropwizard 0.7.1 doesn't depend on the new 2.0 API, but on the old javax.ws.rs:jsr311-api API, which can't handle linking. Or can it? This is the problem I want to solve with Dropwizard. I probably have two ways to do it and I don't know if any of them is valid:
Option 1: I add JAX-RS 2.0 dependency to my project. Voila! I've got Link. But the problem is, that it doesn't work well with old implementations from Jersey - I got AbstractMethodException from UriBuilder, which apparently changed from version 1 to 2. So the answer is to supply new implementations. Can I do it? If yes, than how can I do it? Will new implementations work with dropwizard well?
Option 2: I can just add some other resource linking to dropwizard. Is there some other linking standard/library? I can't use jersey-declarative-linking because it mixes representations with the resources (the linking takes place in representations), and I want my representations not to know a thing about resources layer. So is there another linking standard for Dropwizard, Jersey and JAX-RS 1?

I've finally found an answer to my question.
Option 2 was a dead end. There was no other jax-rs-2-like linking library to either dropwizard or jersey itself.
Option one also was hard to do, but fortunatelly yesterday dropwizard released version 0.8.0-rc1 of their framework, which depends on jersey 2, which is the implementation of JAX-RS 2.0. So for all of you that want to have HATEOAS in dropwizard, version 0.8.0 is for you.

Related

Android spring HATEOAS REST API clientside support with Traverson

im trying to implement an spring android client for a Hypermedia API with responses in HAL format. The Spring HATEOAS - Reference Documentation described the implementation with client side service traversal inspired by the Traverson JavaScript library.
I do this this way:
Traverson traverson = null;
try {
traverson = new Traverson(new URI(getString(R.string.api_test_uri)), MediaTypes.HAL_JSON);
} catch (URISyntaxException e) {
e.printStackTrace();
}
String name = traverson.follow("movies", "movie", "actor").
withTemplateParameters(parameters).
toObject("$.name");
But i'm getting following error while creating a new Traverson object:
java.lang.NoClassDefFoundError: org.springframework.hateoas.hal.HalLinkDiscoverer
Do somebody know how to fix it?
Is there probably other/better ways to support HAL responses in android?
As best I can tell, Spring's Traverson implementation is not usable in Android, because it is part of the Spring HATEOAS module, which depends on spring-core, which ultimately depends on the JDK's implementation of StAX. Android doesn't have a StAX implementation, and because it's in a javax.* package, the Android runtime won't allow you to load one.
In a blog post, Josh Long describes the process of adapting Spring Social and Spring Security to work on Android; essentially, you have to strip out most of their dependencies and selectively re-add only the ones you need. However, you can't work around packages like JAXB or STaX whose Android implementations are incompatible or missing, so you have to rewrite the code that depends on them to use something else instead.
A request has been posted against the spring-hateoas project to support Android, but it was closed (two days ago as I write this) with the comment "we can't commit resources to such a platform specific feature at this time". (On the other hand, someone else seems to be having success with the method described above, so maybe it's worth pursuing?)
Mike Kelly, in his documentation on the HAL standard, supplies a list of libraries that support HAL. I'm currently putting together a solution based on HalBuilder, which looks promising so far.
tl;dr: Spring's Traverson won't work without a lot of effort on your part. You may be better off building your own. Use your favorite HTTP library along with a HAL library, and you're most of the way there.

What is the recommended way to create an ExchangeRateProvider in JavaMoney (JSR 354)?

We have started using the new 1.0 version of JavaMoney API with the reference implementation. Since we have specific Exchangerates that should be used, we need to implement our own ExchangeRateProvider. We have created a class MyRateProvider that extends org.javamoney.moneta.spi.AbstractRateProvider and added MyRateProvider-name to the file META-INF/services/javax.money.convert.ExchangeRateProvider. It works, but all the other providers in org.javamoney.moneta are also loaded even if we are not going to use them. Is there a way to avoid that?
We have an issue today, currently we're looking for modules on moneta.
That we did on this PR: https://github.com/JavaMoney/jsr354-ri/pull/135
That will be fixed on 1.2 version.

jackson 2.4 looking for old class when deserialising

i am developing a restful service with tomcat 7 and jdk 1.6. for json handling i am using jackson 2.4.2 and it works fine except when i try and deserialise an object (that it has no trouble serialising).
the error is:
java.lang.ClassNotFoundException: org.codehaus.jackson.JsonFactory
which is the place where jackson 1.x kept that particular class. my jackson 2.4.2 has it at
com.fasterxml.jackson.core.JsonFactory
i have no idea as to why it is trying to link the old class. i never used jackson 1.x.
what i use:
asm-3.3.1
commons-io-2.4
jackson-core-2.4.2
jackson-databind-2.4.2
jersey-bundle-1.18
mysql-connector-java-5.1.27
and
com.fasterxml.jackson.annotation
which i have taken from github. what library could be trying to import the old jackson module? any help would be much appreciated.
The issue certainly comes from trying to use Jackson 1.x ObjectMapper and missing underlying JsonFactory for 1.x. Since these come from difference jars (jackson-mapper-asl vs jackson-core-asl), it is likely that somehow one is missing.
Now, since you are not directly using Jackson 1.x, question is who is: perhaps jersey is relying on 1.x?
So there are two related questions: (a) if Jackson 1.x is needed, to bring in core jar as well, or (b) how to remove use of Jackson 1.x altogether.
Note that technically it is quite possible to use both 1.x and 2.x versions of Jackson, since 2.x was specifically designed to be able to co-exist. This to make upgrades easier, and allow gradual (component-by-component) upgrading.

Changes done from Spring 2 to Spring 3

Recently while I was upgrading a project in spring 2.5.6 to spring 3.0.5, happened to know that some libraries aren't there anymore and some were renamed like spring-agent to spring-instrument...
Is there any site or a resource to refer to know these sort of changes done in migrating from spring 2 -3 ?
Yes, for most purposes, the Spring Upgrade Guide should provide you with what you need. In particular, check section 2.5 and 2.6 on the new packaging model.
If you are looking for a class that appears to be no longer available, try searching for it with FindJar. Some utility classes have been moved to another packages.

Practical advice on using Jersey and Guice for RESTful service

From what I can find online, the state of the art for Guice + Jersey integration has stagnated since 2008 when it appears both teams reached an impasse. The crux of the issue is that JAX-RS annotations perform field and method injection and this doesn't play nicely with Guice's own dependency injection.
A few examples which I've found don't go far enough to elucidate:
Iqbalyusuf's post on Jersey + Guice on Google App Engine Java suffers from a lot of boilerplate (manually getting and calling the injector). I want binding and injection should happen behind the scenes via Guice annotations.
Jonathan Curran's article Creating a RESTful service with Jersey, Guice, and JSR-250 gave me hope because it's much more current (2010), but went no further than showing how to start up a Jersey service inside of a Guice ServletModule. However, there are no examples of doing any real dependency injection. I suppose that was left as an exercise for the reader. Curran's post may in fact be the correct first step towards wiring up Guice and Jersey and so I plan on starting with that.
tantalizingly James Strachan writes:
JAX-RS works well with dependency
injection frameworks such as Spring,
Guice, GuiceyFruit or JBossMC - you
can basically pick whichever one you
prefer.
But I see no evidence that is true from a practitioner's point of view.
What I find lacking are practical examples and explanations on how to combine JAX-RS and Guice annotations. For instance:
I believe I cannot use constructor injection with any resource as Jersey wants to control this
I'm uncertain whether I can combine #Inject with #PathParam, #QueryParam, et al.
How to use injection in a MessageBodyWriter implementation
Does anyone have examples, preferably with source, of non-trivial application which combines Jersey and Guice without sacrificing one or the other in the process? I'm keeping on this road regardless, but the bits and pieces on the Jersey and Guice lists makes me think I'm repeating the work of others who came before me.
Guice integration with Jersey has not stagnated. The opposite is true. Thanks to Paul and his cohorts behind Jersey, the latest 1.7 release contains a special JerseyServletModule class to work with Guice-based servlets. Guice-based constructor injection into JAX-RS resource works! The issue is using JAX-RS annotations such as #QueryParam in the constructor of a JAX-RS resource. You don't need it! You use Guice for POJO injection all the way including singletons. Then JAX-RS is just icing on the cake for parsing HTTP-based RESTful APIs such as URL path, query parameters, content-type and etc. You don't need an "industrial strength" example either. Both Guice and Jersey are already battle tested. You just need a complete working example to see how it works. Then you can experiment advanced features on your own. Check out the following link for a complete example using Guice 3.0 and Jersey 1.7, which are all latest releases:
http://randomizedsort.blogspot.com/2011/05/using-guice-ified-jersey-in-embedded.html
I created a Guice/Jersey/Jetty/Jackson sample application here:
http://github.com/sunnygleason/j4-minimal
If you have any questions or suggestions for how to improve the
example, feel free to message me via github. The goal is to make
this a very accessible introduction to REST on the Java stack.
Hope this helps - have a great day!
-Sunny
Inspired by Sunnys sample application I've created a similar sample project that uses standard WAR files for deployment, e.g. in Apache Tomcat. You can find the project here:
https://github.com/danbim/template-guice-jersey-tomcat
Have fun!
Daniel
I believe I cannot use constructor
injection with any resource as Jersey
wants to control this
You cannot use guice's constructor injection because creation of resource is managed by jersey. In this case you can use jersey's #Inject annotation before constructor parameter you want to get injected:
public NewsResource(#Inject NewsService service)
I was having similar problems initially trying to use Guice to do constructor injection on my Jersey annotated classes, but eventually got it working, albeit with a fairly trivial application.
I followed the instructions here: jersey-guice javadoc
The trick in my case was that I needed to remove the standard Jersey configuration from my web.xml (like the Jersey ServletContainer) and keep only the Guice listener and Guice filter. Once I did that Guice was being called to create my JAX-RS annotated object, and Jersey was injecting my JAX-RS annotated methods (like #GET, etc.) as expected.
Although Sunny Gleason's example is great, it is a bit outdated now.
So, after struggling a lot today trying to make Guice and Jersey play nice with each other, I created the following sample project to get you started:
https://github.com/MaliciousMustard/gradle-guice-jersey-jetty
This project is using the following technologies:
Guice for DI
Jersey for the RESTful API
Jackson for POJO to JSON mapping
Jetty for the web-server
Gradle
I guess the most important thing is that you don't have to explicitly specify every new resource class you're adding. As long as you're adding them to the package that is being scanned (look at malicious.mustard.modules.JerseyModule), they will be found automatically!
GWizard includes a module that gives you out-of-the-box integration between Jersey2 and Guice. Here's an example of a complete JAX-RS service:
public class Main {
#Path("/hello")
public static class HelloResource {
#GET
public String hello() {
return "hello, world";
}
}
public static class MyModule extends AbstractModule {
#Override
protected void configure() {
bind(HelloResource.class);
}
}
public static void main(String[] args) throws Exception {
Guice.createInjector(new MyModule(), new JerseyModule()).getInstance(Run.class).start();
}
}
Note that this is based on the Squarespace jersey2-guice adapter, which may not function properly with future point releases of Jersey. GWizard also offers a RESTEasy JAX-RS module, which is preferred.
Here is a blog entry about this that might help: http://blorn.com/post/107397841765/guice-and-jersey-2-the-easy-way
The Jersey-Guice plugin Javadoc provides a pretty good description:
http://jersey.java.net/nonav/apidocs/1.1.5/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
These examples were all great starts for me, but I wanted a full MVC stack using Jersey-Guice at it's core. I've been working on refining that for sometime. As of this week this MVC stack is fully deployed to Maven Central repository as an archetype. This means you can now create a new Jersey-Guice stack with one Maven command:
mvn archetype:generate \
-DarchetypeGroupId=org.duelengine \
-DarchetypeArtifactId=duel-mvc-archetype \
-DarchetypeVersion=0.2.1
This automatically generates your own project with you specified package naming so you don't have to manually edit a template project.
See the project Readme.md for more details: https://bitbucket.org/mckamey/duel-mvc
Details on the dual-side views (client-side template & server-side views) I use are here: https://bitbucket.org/mckamey/duel but you could replace with whatever you use.
I found an interesting project for lightweight Jetty+Guice+Jackson web services: https://github.com/talis/jersey-common/
I created a Guice 4.2, Jetty 9.4 and Jersey 2.7 sample application:
https://github.com/bnsd55/jetty-jersey-guice-starter-kit
As Sunny said:
If you have any questions or suggestions for how to improve the
example, feel free to message me via github. The goal is to make this
a very accessible introduction to REST on the Java stack.

Categories

Resources