I am using a class separate from my DAO to handle access requests, but I don't know how to implement InstanceRequest methods:
public class Service
{
public static DAO findDAO(Long id);
}
#Service(Service.class)
public interface DAORequestContext extends RequestContext
{
Request<ProxyForDAO> findDAO(Long id);
InstanceRequest<ProxyForDAO, Long> persist();
}
I define public Long persist() in my DAO implementation, because the gwt docs say, "On the server, instance methods must be implemented as non-static methods in the entity type," but request factory can't seem to find it:
SEVERE: Could not find any methods named persist in com.activegrade.server.data.Service
Feb 23, 2011 10:03:02 PM com.google.gwt.requestfactory.server.ServiceLayerDecorator die
How do I implement an instance method in Service? I don't know how to transform the InstanceRequest. Do I need to connect the DAO class to the Service some way, so that the code generator knows to look in Service for most methods but to skip over to the DAO for InstanceRequest calls?
ASAIK it's not possible because the InstanceRequest methods are bound to the class specified in the #Service annotation. With Request methods it is possible to have a method for multiple data classes one service class, using locators. But from what I understand of request factory this is not possible with the InstanceRequest methods. See also this project, which uses Locators, with methods in one place: http://code.google.com/p/listwidget/
Edit: I've rewritten the answer based after the update/and comment below.
Related
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.
I have a JAX-RS web service that was generated by Netbeans. There are non-abstract facade classes for the service's endpoints. The persistence context is being injected into the non-abstract facade. Everything is working well and I see my data being returned to Fiddler.
We are using DTOs and I am implementing an assembler pattern. So, in the non-abstract facade's constructor, I am creating an instance of the assembler, and am passing the facade's entity manager instance into it. Unfortunately, it seems that the injection of the persistence context has not happened before the facade's constructor has been called, so I cannot pass the entity manager instance into the assembler for its to use in mapping operations. Kind of a chicken-before-the-end situation... I cannot figure out how to make this work... Is there some kind of post-constructor method that I can override and perform the initialization of the assembler and pass in the entity manager to it? I'd really appreciate your help and suggestions.
Thank you for your time and ideas,
Mike
Use method marked with #PostConstruct annotation. Like this:
#PostConstruct
private void init() {
// I'm called after all injections have been resolved
// initialize some object variables here
...
}
In that method you can use both, object fields initialized in the constructor and passed by injection.
I have some service methods which return entities that are not implemented yet.
For example, I have an interface called IUser and some classes that implemented this interface such as GuestUser and AdminUser.
All entity classes are well-defined already and I want to use their jar files without manipulating them.
My problem is when I wanted to define ProxyFor IUser.class in client-side entity and to call service methods that their return type are IUser. While calling these methods I get the following error: The domain type com.bis.entity.security.GuestUser cannot be sent to the client.
Is there any way to call methods that deal with interfaces in RequestFactory or do I have to change all the service methods to utilize class entitis?
You have to use classes for now. See http://code.google.com/p/google-web-toolkit/issues/detail?id=5762
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.
If I use separate service classes with a ServiceLocator, do I still need to define the Locator methods somewhere?:
T create(Class<? extends T> clazz)
I getId(T domainObject)
T find(Class<? extends T> clazz, I id)
Object getVersion(T domainObject)
Do they go on the service class?
In general, these two types serve orthogonal purposes: A ServiceLocator finds code; a Locator finds entities.
Using a ServiceLocator does not change where the entity support methods are declared. The entity support methods are still searched for in the domain types.