alex-shpak / rx-jersey Goto Github PK

I want to call multiple services which have their own auth.
This is in dropwizard
How do I configure more than one client

I'm using the RxJavaInterop library to allow my apps to run both RxJava1 and RxJava2 (partly to allow a gradual transition, but mostly because Hystrix is Rxjava1-only). This is fine because RxJava1 and Rxjava2 are in different Java packages and can co-exist.

However, RxJersey's rxjava-server and rxjava2-server use the same Java package (and the same class names), so you can pick one but not the other. This is a real shame, since from what I can tell they should be able to co-exist otherwise.

Any chance you could use different Java packages for each artifact?

Hi,

I have recently attempted to upgrade to dropwizard 2.0 and use release 0.12 however I have ran across a large change in behaviour in regards to handling exceptions.

These 2 scenarios in version 0.11 and previous are handled the exact same in that no matter which way the exception is returned the correct exception mapper is called.

Scenario 1
public Completable get() { return Completatable.error(new NotFoundException()); }

Scenario 2
public Completable get() { throw new NotFoundException(); }

However after upgrading to 0.12 scenario 2 no longer hits the correct exception mapper. After doing some investigation I found that the actual exception is being wrapped in a InvocationTargetException. This is wrapped when the resource method is invoked in MaybeInvocationHandler::invoke line 34 in version 0.12.

In versions previous to 0.12 e.g. 0.11 etc the exceptions are wrapped in InvocationTargetException by RxInvocationHandler::invoke however these are indirectly executed via ResourceMethodDispatcher::dispatch which has logic inside of it such that if the invoker throws an InvocationTargetException it unwraps it in AbstractJavaResourceMethodDispatcher::invoke line 148.

Should the new MaybeInvocationHandler::invoke perform the same logic that the AbstractJavaResourceMethodDispatcher does, to preserve this behaviour?

This might be a lame/rookie question. Still new to this Rx stuff (pardon my ignorance). Trying to figure out things here.

Will I be able to subscribe to the Server-Side Observable from a Client-Side JavaScript libraries like Angular or react?

The title basically says it all. Instead of specifying an entity to return, I want to (also) modify the request to return a redirect, for example. Is that possible at all?

Is the git example (https://github.com/alex-shpak/rx-jersey/tree/master/example) available in rxJava2?

And unfortunatly the documentation is also not very clear. :'(

https://alex-shpak.github.io/rx-jersey/docs/rx-jersey-server/

but "resourceConfig" is not initiated nor defined?

RxJerseyServerFeature rxJerseyServerFeature = new RxJerseyServerFeature()
                .register(AuthInterceptor.class);

resourceConfig.register(rxJerseyServerFeature);

Hello,

I would like to ask your opinion (and ideas) about the following usecase. Not sure if rx-jersey library is supposed to directly address it, but would be nice to know view of the author (and reader).

Both RX (observable pattern) and event sourcing are becoming popular solutions for today's implementation of services. We would like to leverage rxjava as internal event bus where messages are being published and observed. In this scenario, Jersey becomes just an endpoint which transforms HTTP payload into stream of events (and vice versa).

classical jersey approach

public class MyService {
    @POST   
    @Path("process")
    Single<ResponseEvent> process(RequestEvent event) {
        return Single.just(new ResponseEvent());
    } 
    
    @POST
    @Path("ack")
    Completable ack(AckEvent event) {
        return Completable.complete();
    } 
}

Using RX subject (eventbus)

/**
 * Implementation which uses RX java to process (and publish) events
 */
public class MyService {
    private final Subject<Event> events;
        
    public MyService(Subject<Event> events) {
        this.events = events;
    }
    
    public void start() {
       events.ofType(RequestEvent.class)
           .subscribe(x -> events.onNext(new ResponseEvent()));
           
       events.ofType(AckEvent.class)
           .subscribe(x -> events.onNext(new EmptyEvent()));
    }
}

Our issue becomes correctly mapping request and response events which may span multiple threads (ie having request scope for each event). There are a couple of solutions but none of them is ideal, unfortunately:

1. Having explicit correlationId on each event. The drawback is that it has to be manually copied for each event (eg. new ResponseEvent(request.correlationId())). Which is not nice in business logic.
2. Having separate type Message<T> with payload (which internally stores correlationId and request context). The problem here is that users subscribe to Message and not business level Event (Subject<Message> instead of Subject<Event>)
3. Having continuation-local (for request) variables in RX. Which simulate request scope by using ThreadLocals and custom Schedulers (to copy threadlocal information from one thread to another). see RXJava discussion and schedulers blog post. The issue here is that as soon as events are accessed on the same thread (eg. combined with groupBy) thread-local information will be lost.

Please let me know if there are better alternatives.

Thanks in advance.

I am trying to ue rx-jersey to return a Single from an endpoint created using jersey.
I followed the simple instructions given in the gitbook.
Still I get 500 error response.

Here is my code.
https://github.com/bhargodevarya/JerseyBackendExp

public class Main {
public static final String BASE_URI = "http://localhost:8080/myapp/";
public static HttpServer startServer() {
final ResourceConfig rc = new ResourceConfig().packages("JeyseyBackendExp");
rc.register(RxJerseyServerFeature.class);
rc.register(RxJerseyClientFeature.class);
return GrizzlyHttpServerFactory.createHttpServer(URI.create(BASE_URI), rc);
}
public static void main(String[] args) throws IOException {
final HttpServer server = startServer();
System.out.println(String.format("Jersey app started with WADL available at "
+ "%sapplication.wadl\nHit enter to stop it...", BASE_URI));
System.in.read();
server.stop();
}
}

The resource being returned is :-

@path("myresource")
public class MyResource {
@get
@produces(MediaType.TEXT_PLAIN)
@path("test")
public String getIt() {
return "Got it!";
}

@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("rx")
public Single<String> rxSetup() {
    return Single.just("rx setup done");
}

}

Hi Alex,

Any chance you can publish the 0.9.0 release to Maven Central?

Is it possible to upload artifacts to maven central ?
In some corporate environments it is the only available (external) maven repository.

After running gradle clean test a couple of times, the follwing tests fail sporadically:

net.winterly.rx.jersey.JsonResourceTest > shouldReadJsonEntities FAILED
net.winterly.rx.jersey.JsonResourceTest > shouldWriteJsonEntities FAILED

Error message

org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: 
MessageBodyReader not found for media type=text/html;charset=ISO-8859-1, 
type=class net.winterly.rx.jersey.JsonResourceTest$Message, genericType=class 

I believe something is wrong with imported libraries (providers).

After deploying rxjersey to production in a DropWizard application, I noticed my REST endpoints that returned Completable suddenly started responding with HTTP 500 after a short period of operation, and only a restart would fix them, after which they would resume the 500s shortly afterwards.

I've managed to narrow it down to a simple reproducible test case, the source of which can be found at rxjersey-loadtest. A simple mvn clean test will demonstrate the bug.

The source consists of a skeleton DropWizard application that registers a single REST resource and a ContainerResponseFilter. The filter adds a header to the HTTP response.

The unit test starts up the application and hits it with 1000 sequential GET requests to the REST resource, at at request number 677 (on my machine, possibly this varies) the application craps out with an HTTP 500. The test also prints out the response headers it gets back each time, and with each subsequent response you can see the HTTP header added by my filter being duplicated. My assumption is that it hits an internal hard limit inside Jersey.

When I change the REST resource to return a vanilla (non-RxJersey) 204 Response, it runs fine to completion, with the single header printed each time. If I change the resource to return an empty Observable instead of Completable, it also fails. If I use a non-empty Observable`, it works fine. If I remove the filter, or stop it from adding the header, it works fine.

I ran it through a debug session in my IDE, with a breakpoint inside the filter, and it looks like the messageContext field of the ContainerResponseContext is the same object each time, as though it's being recycled between requests.

I've no idea why this would only happen for Completables and empty Observables.

Hello,

First of all, thank you for this nice integration work (jersey + rxjava).

Would it be possible to add support for rx java 2.0 as well ?

I presume it should be a separate package / module.

Thanks.