Hi Josh apologies for a late response...
On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <[email protected]>wrote: > I'm picking up this old thread again in hopes that my use case can be > addressed in CXF. I modified pax-web to look for and, if available, use a > custom HttpContext as the default context. I then defined and registered > the HttpContext in another bundle. However, CXF isn't able to register > servlets properly using this HttpContext. This might be because that > HttpContext can't properly implement the "public URL getResource(String > name)" method, since it doesn't have access to the right classloader. > S.B : it is probably a better solution, having pax-web checking for a custom HttpContext...But the problem you're seeing with a custom one could show up even if CXF detects a custom context, as suggested earlier on. Do you see some stack trace from CXf DSW or paxweb reporting some exception ? > So I'm going to ask my question in a slightly different way in hopes that > the details of this experiment don't send us off track: if you needed to > apply spring security filters to all DOSGi endpoints, how would you do it? > > S.B. My limited experience with SpringSecurity tells me a CXF servlet should have a Spring security filter for a start, is it possible to set up pax-web such that adds a filter to all servlets ? Next, you can probably register a Spring DM context and rely on the URI-related Spring Security configuration Let us know please how it goes on... thanks, Sergey > Thanks, > Josh > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <[email protected] > >wrote: > > > 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 > >>> > >>> > >> > > >
