Interesting, I wasn't actually talking about HA protocol metadata - that would be really cool if it could be used to completely eliminate at least one custom dispatch. Otherwise, there may not be enough utility if you end up needing code anyway.
In the near term, I think that dispatch classes like the one for Storm can be eliminated with configuration for excluded headers and identity assertion param names. That might be a good goal for an 0.6.1 release. On Tue, May 12, 2015 at 10:57 AM, Sumit Gupta <[email protected]> wrote: > +1 to the concept of adding some more obvious named parameters (like the > ones you mentioned) to the dispatch part of the service definition. I > started going down that path in the first cut of the service definition > work but reverted when I got bogged down thinking about parameters that > can be overridden/configured in topology files versus what is Œfinal¹ in a > service definition. A trivial example of the parameter that can be in the > topology files is ŒreplayBufferSize¹. > > Also agree on the HA side of things. We probably need to look at some more > HA implementations but we could probably get a lot of boiler plate code > out of the way by allowing a service to declare all the errors that it > would like to failover on and all the errors to retry on. Pinging servers > and finding the next available is another storyŠ > > Sumit. > > > On 5/11/15, 7:08 PM, "larry mccay" <[email protected]> wrote: > > >All - > > > >I think we need to determine the best way forward for our trusted proxy > >support. > > > >Today, we have the details of the various ?doAs= vs ?username= parameters > >in the identity assertion httpServletRequestWrapper. > > > >Some services are coming into the fold with new or just plain different > >query parameter names. > > > >At this point, I believe our only course of action is a custom dispatch > >class for these services. Given that this is a constant and requires no > >real dispatching logic - I feel that we should avoid the custom code. > > > >This means that the values of the identity assertion parameters need to be > >configurable for each service. I would say this is true of anything that > >doesn't require custom dispatch logic. If we can avoid custom dispatches > >then we should do what we can to do so. > > > >That said, I think that we have at least two types of dispatches: > > > >1. Some flavor of the DefaultDispatch class with variations of parameter > >names, maybe additional parameters, headers, etc. Even HA related code may > >fall into this category of dispatch. Currently, any HA handling requires a > >custom dispatch. > > > >2. Completely different dispatch code that may even require a different > >client from HttpClient. > > > >For #1 we should be able to cut down on the number of custom dispatches by > >making certain things configurable - hopefully through the service > >definition itself. > > > >* identity assertion parameter names - for secure and unsecured clusters > >* excluded headers - some services require all the original headers - > >others do not > > > >Parameter names can be done in a couple different ways. We can move all > >the > >logic for determining the names to use into dispatch. This has been on the > >radar for some time as something that seems better architecturally. There > >*may* be some assumption that it has occurred already between the identity > >assertion provider and the dispatch but I'm sure if there is that it can > >be > >dealt with. > > > >The other is to leave it the way it is and intercept the request in the > >DefaultDispatch - or HttpClientDispatch layers and apply some rewrite to > >the query string to replace doAs with the configured value. This feels a > >little hacky but would work fine. > > > >This feature would allow us to work on service definitions even while the > >components are still working on adding trusted proxy support and we not > >end > >up surprised with an incompatibility due to a name mismatch. > > > >Thoughts? > > > >--larry > >
