allow access to headers

[cazacugmihai]

Allow writing and reading headers for EventBusService.

E.g.:

EventBusService.getProxy(discovery, SomeService) { AsyncResult<SomeService> ar1 ->
    SomeService someService = ar1.result()
    // here, it will be nice to have an option to allow *sending* some headers along the "someCommand"
    someService.someMethod(someCommand) { AsyncResult<SomeResult> ar2 ->
        // do something
    }
}

interface SomeService {
    // here, it will be nice to have an option to allow *reading* headers along the "someCommand"
    void someMethod(SomeCommand someCommand, Handler<AsyncResult<SomeResult>> handler) {
        // do something
    }
}

[cazacugmihai]

It was moved here because of this comment.

[cazacugmihai]

Are there any progress on this one?

I have seen that it was mentioned in 3.5.0-Release-Notes.

Thank you!

[diliuskh]

@cazacugmihai there is a workaround for your problem. Proxy class and handler are generated using handlergen.templ and proxygen.templ files in service-proxy module. You could modify them so that proxy sets message headers using io.vertx.core.Context.get and handler puts received headers again using Context class. No recompilation of codegen or service-proxy modules required. Just add modified template files to your classpath during compilation.

[cazacugmihai]

@diliuskh: Thanks, I did'n know that! It would be wise to have this provided by default in the API.

[slinkydeveloper]

Close as inactive, reopen if you need it

[vVv-AA]

@slinkydeveloper The solution given by @diliuskh wont work with 4.0 right? Seems like the gen logic is hardcoded into classes now. Is there a work around for this?

[vVv-AA]

@slinkydeveloper @vietj Any workaround for this ^

[slinkydeveloper]

Not that I'm aware of, It seems like nobody was interested in this feature anymore... are you willing to contribute to this feature?

[vVv-AA]

@slinkydeveloper

I can try with some guidance. I believe these we would pass a key from the caller, then the proxy picks the data from local context and adds it to deliveryoptions as a header, then the passed header gets set into the local context back again on the service side? Or maybe the headers can be explicitly passed?

Do you have any suggestion on the header name?

[slinkydeveloper]

@vVv-AA that sounds a bit complicated... I do wonder, why you need message headers? Why not just passing a map in the signature of the proxy interface?

[ddcprg]

This is a feature that I really need. Is anyone working on this ticket? I could help

[slinkydeveloper]

@ddcprg afaik nobody is working on this, do you want to give it a try?

[ddcprg]

Sure thing @slinkydeveloper