Resteasy generally enable GZIP - resteasy

I have a RestEasy + Java EE application. When I add #GZIP to a component class, the server-answer is gzipped, if the client sends "accepts:gzip"
Is there a way to generally enable gzip for all components? I don't like to add the annotation to every class.
I'm using RestEasy JAX-RS 3.0.1

if you are implementing your API behind an interface, so all your interfaces might inherit from one interface let us name is "BaseAPI"
and logically if you set #Gzip on the BaseAPI so it would apply Content-Encoding for all inherited interfaces and method.
#GZIP
public interface BaseAPI
{
}
public interface APIX extends BaseAPI
{
#GET
Response getSomething() {
}

No, there is no way with annotations to enable gzip for all resources. If you wanted to forego adding the annotation to every class you could create a servlet filter that looks at the incoming headers and gzips the response on the way out.

You can do this with custom JAX-RS 2.0 filters and interceptors, and it's not even particularly hard once you know how.
What you'll need to do is add a filter that modifies the existing ones for GZIP so it does not check for the annotation to be present to support the encoding, it only looks for the Accept-Encoding header.
Look at how RestEasy GZIP encoding is implemented:
https://github.com/resteasy/Resteasy/tree/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/interceptors/encoding
You'd need to add Features that have method configure(ResourceInfo resourceInfo, FeatureContext configurable) which always add the GZIP filters, regardless of annotations present. You'll need one Feature that registers a custom Filter for Server, and one for Client.
With those in place, the pre-existing GZIP interceptors should do the rest of the work.
I've used similar mechanisms to create a custom compression filter (although I ended up setting it up to be applied by annotation to limit scope).

Use Apache for this. Apache can handle it automatically and optimize (gzip in your case) all your responses to clients. It will not only gzip it, but also attach all necessary response headers, that allow clients identify, that content is zippid to let them unzip it.
No changes in the code is needed for this issue.

Reasteasy has this GZIPDecodingInterceptor. So, you can do this when you create the client:
import org.jboss.resteasy.plugins.interceptors.GZIPDecodingInterceptor;
import org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl;
ResteasyClient client = new ResteasyClientBuilderImpl().build();
client.register(GZIPDecodingInterceptor.class);

Related

Websocket with codename one

Will be be able to use the same websocket code for JS too? or is there any special code needed depending on platform?
Also will we be able to extend URLImage.createToStorage() method to load from our own websocket based backend rather than from URL? and will it be possible to make it work seamless in all devices?
It is possible to use websockets for the connection from a JavaScript build see this discussion. Notice that if you need to connect to a different server from the origin you will need to proxy your request to keep the same origin behavior.
You can't override the create methods of URLImage as they are all static. You can however download the files thru a websocket and open them using the EncodedImage.create method that accepts a byte array.

authentication/http headers support in forge.file trigger.io module?

in the official trigger.io docs there seems to be no provision for custom http headers when it comes to the forge.file module. I need this so I can download files behind an http authentication scheme. This seems like an easy thing to add, if support is not already there.
any workarounds? any chance of a quick fix in the next update? I know I could use forge.request instead, but I'd like to keep a local copy (saveURL).
thanks
Unfortunately the file module just uses simple "download url" methods rather than a full HTTP request library, which makes it a fairly big task to add support for custom headers.
I've added a task to our backlog for this, but I don't have a timeframe for it being added.
Currently on iOS you can do basic auth by using urls in the form http://user:password#url.com in case that helps.
Maybe to avoid this you can configure your server differently, or have a proxy server in front that allows you to pass authentication details as get parameters?

How to dynamically map URLs to Java servlet handlers based on their names? (Google App Engine)

What I'm looking for is some sort of class or annotation I can add to Java classes that are dedicated to handling specific requests, and having URLs map to these based on their name. For example, have the URL ".../api/GetContactsRequest" map to a handler named GetContactsRequest (or 404 if no such handler exists). I know I could write servlets and map each URL to each servlet, but I figure the less boilerplate routing code/configuration, the better! These will mostly be application request handlers, communicating using JSON. I haven't figured out how I'll be handling static requests, but I'll most likely just be sending a big web application at the user that navigates itself or something.
For background, I'm using the Google App Engine so I have access to yaml configurations and their servlet APIs. So is there a standard way of doing this with either the Java servlet APIs or the Google App Engine-specific framework? I've only ever used specific Java servlet frameworks like Apache and stuff before, which were all already built by the time I started working on them, so I really don't know what there is to use with this environment. I'm also new to this all in general, and having trouble wading through what Servlets, Services, Filters, Listeners, and Handlers all are, and which is best for this simple routing behavior that I want/need. I'm worried I'll pick the wrong one, or don't even know of the one that would suit my needs.
This is what JAX-RS does - not exactly class name mapping, but mapping via annotations. See some of the features.
There are several implementations, personally I use RESTEasy - it works flawlessly on GAE. Additionally I use Jackson (comes with RESTEasy) to produce JSON.
If you need to produce html then look at htmleasy - it's a thin layer on top of RESTEasy enabling use of different html templating libraries. It'll help you separate logic from presentation.
EDIT:
If you really want to avoid using standard libs and writing something on your own, then write a servlet filter that inspects the request and forwards it to your servlet (or invoke custom code):
public class ForwardFilter implements Filter {
#Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) {
if(request.getRequestURI().equals("/some/path")){
request.getRequestDispatcher("/path/where/servlet/registered").forward(request, response);
return; // prevents normal request processing
}
// you need this for normal request path
filterChain.doFilter(request, response);
}
}

UTF-8 For Restful Services

Currently i enable UTF-8 as #Consumes("application/xml;charset=utf-8") in the RESTful Services for the different methods. I am interested to see if we can change this for all REST services with a single configuration change. We are using CXF, maybe there is something it provides?
Thanks
Ravi
The first question is are you sure you want to prevent any of your rest resources from accepting non-UTF-8 entities? Such an across the board proclamation feels like it could cause trouble down the road.
I'll admit that I haven't used CXF so I can't speak to those specifics. But I can think of one option each under the JAX-RS and Servlet APIs which might be along the lines of what you seek to accomplish.
Using the Servlet API: Depending on how you are deploying your application you might be able to create and inject a servlet filter. In the doFilter method, you can check the encoding of the request entity and continue on to the next part of the filter chain (ultimately to the rest application). If an improper entity is sent on the request, you would just set the appropriate HTTP 415 status onto the response and not invoke your rest application.
Using JAX-RS: Depending on how you parse/accept the entity body in your resources, you could create and inject a custom MessageBodyReader implementation. This reader could parse your entity, ensuring that it is UTF-8 only and throw an appropriate exception otherwise.

GWT: Where (how) to define POJOs to make em available for client and server? (and to use datastore on serverside)

I try to get an application running which should interact with a server via RPC (JDO in Google DataStore). So I defined a persistent POJO on the server-side to get it put in the datastore via the PersistenceManager (as shown in the gwt rpc tuts). Everything works fine. But I am not able to receive the callback POJO on the client side because the POJO is only defined on server-side. How can I realize it, that the client knows that kind of object??
(sry for my bad english)
Lars
Put your POJOs in a separate package/directory (e.g. com.example.common) and then add source declaration to your GWT module descriptor (xyz.gwt.xml):
<source path="common"/> //relative to your xyz.gwt.xml location
GWT compiler will then also compile POJOs and they will be seen by your other GWT code.
Edited:
#Lars - now I understand your problem. As I see it you have several options:
If possible use Objectify instead of JDO. Objectify uses pure POJOs and they play nicely with GWT. I use this in my projects. One nice thing that Objectify gives you is #PostLoad & # PrePersist on methods to run some code before/after POJOs are loaded/saved to datastore. I use this to handle serialization of GeoPoint for instance.
Use JDO and make copies of your domain classes. This is a pain but it would work. Use 'transient' java keyword in your server JDO classes to exclude fields you do not want to RPC.
Edit #2: There is a third option that you might prefer:
Create "fake" JDO annotation classes using super-sourcing. This is a common technique to replace classes with a GWT version. Described here: http://fredsa.allen-sauer.com/2009/04/1st-look-at-app-engine-using-jdo.html
You can use DTO(stackoverflow, moar) for transferring data to client.
Basic sample here (method getTenLatestEntries() in your case).
Or you can use some third-party libraries like objectify and stop worry about making DTO`s.

Resources