Checking the osgi service registry for a custom HttpContext makes sense to me, but it introduces a startup order problem. If CXF can handle that, then we're in good shape.
I'll have a look at pax web to see what I can do there in the meantime. Thanks, Josh On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <[email protected]>wrote: > Hi Josh > > We've chatted with David a bit about it... > Are you actually proposing for CXF DSW to check for a custom HttpContext > implementation registered as an OSGI Service ? It would make sense...It > would probaly make sense to have an additional list property passed along > during the custom HttpContext registration, which will list custom > interfaces (possibly with wildcards) and which CXF DSW will check to ensure > it does not attach a 'foreign' HttpContext to a given servlet endpoint... > > In meantime, may be paxweb can let users specify a custom HttpContext in > the system properties which it will use instead of the default impl ? If it > were possible then it could help till the proper fix goes in. > > Cheers, Sergey > > > DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which >> means that the HttpService will create a default context. This makes it >> hard to add pluggable authentication handlers using >> httpContext.handleSecurity(). Does anyone have suggestions for hooking >> into >> the request before it's sent to the JAX-RS resource methods? I'd prefer >> to >> bind to the OSGI APIs rather than to CXF, and it seems like the >> httpContext >> should be a good way of doing that. >> >> If there isn't a convenient plact to hook in, I suppose I'll have to >> provide >> a custom HttpService that overrides >> HttpService.createDefaultHttpContext(). >> >> Thanks, >> Josh >> >> >
