2017
January
-
Struggling with Swagger Codegen
For both my day job and a side project, I need want to generate and manage my REST APIs in a contract-first manner using Swagger. From looking at the docs, the answer seems to be Swagger Codegen, but I’m finding that it’s not that simple.
- Getting Started with Swagger and JAX-RS
2015
November
-
Kotlin-RS
In keeping with theme of "use existing frameworks with Kotlin" and misleading titles, here’s a quick and dirty demonstration of writing JAX-RS applications using Kotlin.
2014
August
-
Can I Use Dropwizard for This?
I’ve been toying with using DropWizard as my… deployment platform for a personal project, but I need/want JAX-RS 2 and CDI, which is a problem for the the stable DW. There is a branch that is migrating to JAX-RS 2 (and Jersey 2.9), and it sort of works, but trying a simple injection is causing a failure I can’t quite figure out:
Caused by: A MultiException has 1 exceptions. They are: 1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=SayHelloService,parent=HelloWorldResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,288169102) at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74) at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:838) at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:890) at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:880) at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:517) at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163) at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285) at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:310) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:540) ... 36 more Caused by: org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=SayHelloService,parent=HelloWorldResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,288169102) ... 55 more
If I create the Weld runtime and request the beans specifically, I get to good objects (instances of both A and B, with B having an injected instance of A), but once I tell DW to fire things, the app dies:
1 2 3 4 5 6 7 8 9 10 11 12
Weld weld = new Weld(); WeldContainer container = weld.initialize(); container.instance().select(SayHelloService.class).get(); SayHelloService service = WeldContext.INSTANCE.getBean(SayHelloService.class); final HelloWorldResource resource = container.instance().select(HelloWorldResource.class).get(); resource.setTemplate(configuration.getTemplate()); resource.setDefaultName(configuration.getDefaultName()); final TemplateHealthCheck healthCheck = new TemplateHealthCheck(configuration.getTemplate()); environment.healthChecks().register("template", healthCheck); environment.jersey().register(resource);
It seems, then, my deployment environment will be, at least for now, a Java EE app server. They’re small enough these days that it really shouldn’t matter. I was just curious to see if DW might be viable for me, and it appears that the answer is "not yet".
I’ll check back later.
May
-
File Uploads with JAX-RS 2
If you search for how to upload a file to a JAX-RS 2 endpoint, most suggestions will point you to implementation-specific approaches. While that works, it defeats one of the purposes of a spec: portability. There are some posts out there that will point you in the right direction, though. What I’ll do here, then, is present a clear, portable solution to the problem.
2013
July
-
A Simple OAuth2 Client and Server Example: Part II
In the last post, we took a look at the server side of our OAuth2 system. In this post, we’ll take a quick look at the unit tests that will act as TheUser.
-
A Simple OAuth2 Client and Server Example: Part I
When implementing web site security, OAuth2 almost always comes up. We’ve had requests to implement OAuth2 in the GlassFish REST interface, and, it turns out, I have a similar need on a personal project. Looking at the spec, though, OAuth2 can be pretty daunting. Fortunately, you don’t need to understand it all, and Apache has a project, Oltu (nee Amber) that handles most of the implementation.
April
-
Initializing JAX-RS Sub-resources
This morning, I was reading through the Proposed Final Draft for JAX-RS 2.0 specification, when I found a little nugget that could have saved me some work, specificially in initializing subresources.
2012
January
-
A Jersey POJOMapping Client/Server Example
JAX-RS is the specification that describes how to build RESTful interfaces in a Java EE environment. Jersey is the reference implementation of that spec, and, like many implementations, offers features above and beyond what spec does. One feature that I’ve been working with recently is the POJOMapping feature, which makes writing services and clients much easier, as well as typesafe.