I am working in a RESTful application developed in Apache CXF and I would like to introduce hypermedia functionality to it.
Most of our jaxrs:serviceBeans follow this template:
#GET
#Path("/{exampleId}")
public ExampleJSON get(#PathParam("exampleId") Integer exampleId) {
ExampleJSON example;
// Load data from repository here...
// Add link to self.
String href = javax.ws.rs.core.Link.fromResource(ExampleService.class).build().getUri().toString();
// HypermediaLink is a custom object to hold a "href" and "rel" strings
HypermediaLink linkToSelf = new HypermediaLink();
linkToSelf.setHref(href + example.getId());
linkToSelf.setRel("self");
// Inherited method, just adds a HypermediaLink to a collection in the parent class
example.addHypermediaLink(linkToSelf);
// Return JSON compatible object, JACKSON will serialize it nicely.
return example;
}
This is the basic concept. Keep in mind that I simplified this code for explanation purposes; so, it can be easily understood.
This code works fine; but I am wondering if there is a better way to do this with Apache CXF. I have some ideas for how to enhancing it; however, it will require some custom annotations.
I see some examples using Jersey, but I would like to stick with Apache CXF.
Any help would be appreciated.
Thanks
I would leverage some features of JAX-RS and / or Jackson to implement the link adding under the hood at the serialization level. So you wouldn't need to have a specific field for the link within the bean itself.
You could implement a custom MessageBodyWriter to generate a different JSON payload (for example) for your POJOs than the default. So you could dynamically add the link.
See this answer for more details: How to write an XML MessageBodyWriter provider with jersey.
If you use Jackson for the serialization, you could implement a custom serializer. Note that this is generic and will work for all supported format of Jackson.
Below is a sample code:
public class LinkBeanSerializer extends JsonSerializer<SomeBean> {
#Override
public void serialize(SomeBean bean, JsonGenerator jgen,
SerializerProvider provider) throws IOException,
JsonProcessingException {
jgen.writeStartObject();
// Fields
jgen.writeNumberField("id", bean.getId());
// Things could be generic using reflection
// Link
String href = javax.ws.rs.core.Link.fromResource(SomeBean.class).build().getUri().toString();
HypermediaLink linkToSelf = new HypermediaLink();
linkToSelf.setHref(href + bean.getId());
linkToSelf.setRel("self");
jgen.writeObjectField("hypermediaLink", linkToSelf);
jgen.writeEndObject();
}
}
Note that we could make this serializer more generic I think (something like extends JsonSerializer<Object>)
See this answer for more details: Processing JSON response using JAX-RS (how to register the custom serializer within JAX-RS, ...).
Perhaps implementing a WriterInterceptor could solve your problem but there is impact on the beans since you need to have field hypermediaLink. The interceptor could be responsible of filling the field.
See this answer for more details: Jersey Update Entity Property MessageBodyWriter.
IMO the more convenient solution is the second one. It's transparent and support all the formats supported by Jackson.
Hope it helps you,
Thierry
Related
The documentation for defining general API information using the quarkus-smallrye-openapi extension is extremely sparse, and does not explain how to use all the annotations for setting up the openApi generation.
For some background, I am using a clean and largely empty project (quarkus version1.0.1.FINAL) generated from code.quarkus.io, with a single class defined as followed (With the attempted #OpenAPIDefinition annotation):
#OpenAPIDefinition(
info = #Info(
title = "Custom API title",
version = "3.14"
)
)
#Path("/hello")
public class ExampleResource {
#GET
#Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
}
I have eventually found that general api information (contact info, version, etc) through much digging is defined using the #OpenAPIDefinition annotation, but when used on my existing endpoint definition, no changes are made to the generated openapi specification. What am I doing wrong?
Try putting the annotation on the JAX-RS Application class. I realize you don't need one of those in a Quarkus application, but I think it doesn't hurt either. For reference in the specification TCK:
https://github.com/eclipse/microprofile-open-api/blob/master/tck/src/main/java/org/eclipse/microprofile/openapi/apps/airlines/JAXRSApp.java
1) What is a JaxB provider, and is it the same as a ContextResolver?
2) What is a jaxb handler?
I'm very lost in these terminologies. Please reply in simple to understand words.
Here it is from the book:
JAXB JAX-RS Handlers
The JAX-RS specification requires implementations to automatically support the marshalling and unmarshalling of classes that are annotated with #XmlRootElement or #XmlType as well as objects wrapped inside javax.xml.bind.JAXBElement instances. Here’s an example that interacts using the Customer class defined earlier:
#Path("/customers")
public class CustomerResource {
#GET
#Path("{id}")
#Produces("application/xml")
public Customer getCustomer(#PathParam("id") int id) {
Customer cust = findCustomer(id);
return cust;
}
#POST
#Consumes("application/xml")
public void createCustomer(Customer cust) {
...
}
}
As you can see, once you’ve applied JAXB annotations to your Java classes, it is very easy to exchange XML documents between your client and web services. The built-in JAXB handlers will handle any JAXB-annotated class for the application/xml, text/xml, or application/*+xml media types. By default, they will also manage the creation and initialization of JAXBContext instances. Because the creation of JAXBContext instances can be expensive, JAX-RS implementations usually cache them after they are first initialized.
Managing your own JAXBContexts with ContextResolvers
If you are already familiar with JAXB, you’ll know that many times you need to configure your JAXBContext instances a certain way to get the output you desire. The JAX-RS built-in JAXB provider allows you to plug in your own JAXBContext instances. The way it works is that you have to implement a factory-like interface called javax.ws.rs.ext.ContextResolver to override the default JAXBContext creation:
public interface ContextResolver<T> {
T getContext(Class<?> type);
}
ContextResolvers are pluggable factories that create objects of a specific type, for a certain Java type, and for a specific media type. To plug in your own JAXBContext, you will have to implement this interface. Here’s an example of creating a specific JAXBContext for our Customer class:
#Provider
#Produces("application/xml")
public class CustomerResolver
implements ContextResolver<JAXBContext> {
private JAXBContext ctx;
public CustomerResolver() {
this.ctx = ...; // initialize it the way you want
}
public JAXBContext getContext(Class<?> type) {
if (type.equals(Customer.class)) {
return ctx;
} else {
return null;
}
}
}
JAXB Provider
A JAXB provider is an implementation of the Java Architecture for XML Binding (JSR-222) specification. This specification was created through the Java Community Process. It was originally lead by Sun Microsystems, but is now lead by Oracle. The expert group had members from several object-to-XML technologies (XMLBeans, EMF, TopLink OX, etc) as well as several individuals. A JAXB implementation is required to pass the Test Compatibility Kit (TCK). Below are links to a couple of JAXB providers:
https://jaxb.java.net/
http://www.eclipse.org/eclipselink/moxy.php
ContextResolver
JAXB is the default object-to-XML provider in JAX-RS. By default it will create a JAXBContext based on the parameter/return type of the JAX-RS annotated method (i.e. annotated with #GET). Then it will pull in all referenced classes to produce metadata as well. Sometimes this doesn't produce all the required metadata and you need to provide the JAXBContext yourself. This can be done with a ContextResolver.
JAXB Handler
I'm not familiar with this term.
JAXB is the acronym for "Java Architecture for XML Binding", a specification defining ways to convert between XML documents and Java object trees, originally created by Sun Microsystems. The valid spec, version 2.0, was completed in 2006.
An implementation according to the JAXB specification is a JAXB provider.
The specification contains some hints, what a plausible implementation might contain. For instance: "The JAXBContext class is the entry point for a Java application into the
JAXB framework." It maintains information about the classes to expect during (un)marshalling. It is created either from one or more packages or from a list of classes. (The process of context resolution may follow hints in the annotation.)
The term "JAXB handler" (as it is used in the quoted text) refers to the code associated with a JAXBContext class that investigates a Java class, introspecting fields and methods and annotations, thus creating a database of all information contained within the Java code.
The Header section (Apache Tiles Attribute) is shared by several views. It has a form that expects an Object when the page is loaded and complains if the Object is missing. At the moment I am placing the Object in a Model and passing it to the View using the Controller every time I create a view that inherits this layout.
This approach seems rather tedious as i have repeated lines all over the Controller. I'd like to be able to add it once and be done with.
I am not too familiar with Apache Tiles there maybe a simple solution that I am not aware of.
Looking for some helpful tips.
Thanks
You can use the HandlerInterceptorAdapter class and the postHandle method to achieve something like that. By cons, you will need to define a rule that will help you to know when the object need to be add to the model, it can be the path or something in the url, it depends on how your template is organized. Here an example of an interceptor that is doing something like that.
The interceptor defenition :
<mvc:interceptors>
<bean class="your.package.HeaderModelInterceptor"/>
</mvc:interceptors>
The interceptor class :
public class HeaderModelInterceptor extends HandlerInterceptorAdapter {
#Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
ModelAndView modelAndView) throws Exception {
// Check if you need to add the object
if (Your rule) {
modelAndView.addObject("headerObject", headerObject);
}
super.postHandle(request, response, handler, modelAndView);
}
}
You have a couple of options to do this. Off the top of my head you could.
Use Tiles view preparers, simple example here
Use a mechanism like Spring interceptors or AOP to automatically add your object to the Model instead of repeating the code everywhere
It really depends on the nature of the object you're adding and how much context it needs.
We are using CXF 2.4.2 to create a RESTful interface. I have a bean resource class that is defined as follows:
#Path("/mypath")
public class MyResource {
#GET
#Path("/myget")
public final Response myGet() { ... }
Does anyone know why the method can't be final in order to access the resource?
Sometimes JAX-RS is implemented in such a way, that instead of original class (that we create) JAX-RS is using proxy class which inherits from our class. Since final method cannot be overriden, usage of final methods is prohibited.
Usage of proxy enables adding to JAX-RS framework various interceptors, providers, etc. Obviously the same functionality can be obtain without using proxy, so other providers might allow usage of final methods.
The specification does not say anything about final methods.
Side note: very often usage of final method is a bad idea. Sometimes even if we think that given method should not be overriden, it may appear that is necessary. Even Java creators made a few such mistakes. Obviously there are classes, which methods should not be overriden (String), but there are not a lot of them.
I have a Jersey client that is hooked up using Guice. Really hooked up :)
The resources are also created using Guice.
Something like:
#Inject
class TestResource {
#Inject DataFatcher fetcher,
...
...
}
Now, DataFetcher object is created using Guice and has deep nested guice-created objects using composition. Now, some of these object need access to parameters passed over using POST.
I have a HttpServletModule that does that for me. I I thought that does the right work.
HttpServletModule.java
Map<String, String[]> providerRequestParametersMap(HttpServletRequest reuquest) {
request.getParametersMap()
}
Now, unfortunately, It looks like Jersey, has already intercepter the request and removed the POST parameters from the request parameters Map. So, this Map of mine is empty.
How, can I get access to the POST Parameters in Guice ? I do not want to Inject the Form of MultivaledMap in the Resource directly, since that will need to be passed down all the way from the Resource which will mess up my design.
Any tips greatly appreciated. I can think of creating a Filter that intercepts the HttpServletRequest before the Jersey filters kicks in. Hoping that there is a better,easier solution :).
The easiest solution is probably a servlet Filter that does what you suggest: intercepting the HttpServletRequest before it's handled by Jersey and setting data in a request-scoped object.
If you're using Guice Servlet, filtering is at least a few keystrokes less setup than it is in web.xml.
If you'd prefer a Jersey-only solution, you could use a ContainerRequestFilter. This gives you access to ContainerRequest, which in turn provides you with a Form (a javax.ws.rs.core.MultivaluedMap).