Very helpful, thanks! I didn't realize that DOSGi intercepts service calls from the local osgi container, but I suppose it must in order to provide QoS concepts.
Thanks, Josh On Thu, Jun 18, 2009 at 3:04 PM, Eoghan Glynn <[email protected]> wrote: > Hi Josh, > > Sounds like you need a custom intent. > > An intent is simply a string that identifies some QoS that should be > enabled > on the local proxy or is required by the remote service. The desired > intents > are specified via a space-separated list provided as a property on the > service lookup (check with DavidB for the latest property name, these have > been changing recently due to some churn in the specification process). > > Now dOSGi uses a master intent map, that's retrieved from > /OSGI-INF/cxf/intents/intent-map.xml in the DSW bundle. > > But you can provide your own application-specific intents in the calling > bundle (same path as above) which would then be merged with the master map. > > As you can see from [1], the intent map is simply a string-to-bean map > where > the key is a string intent name and the value is a CXF Feature, list of > WS-Policy assertions or a BindingConfiguration. > > So your custom map could look something like this: > > <beans xmlns="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:auth="http://holtzman.org/auth"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd";> > > <bean id="intentMap" class="org.apache.cxf.dosgi.dsw.qos.IntentMap"> > <property name="intents"> > <map> > <entry key="authorization" value-ref="joshAuth"/> > </map> > </property> > </bean> > > <auth:authorization id="joshAuth"/> > </beans> > > Then your authorization feature would simply install the required > interceptors, on the individual proxy created for the remote service. > > You can model your feature implementation on the WSAdedressingFeature[2], > which is one of the simplest in CXF. > > You'll also need need a META-INF/spring.handlers file mapping your > namespace > to a handler class, e.g.: > > http\://holtzman.org/auth=org.holtzman.auth.spring.NamespaceHandler > > Then just base the namespace handler and bean definition parser on the WS-A > analogues ([3], [4]). > > Hope this helps! > > Cheers, > Eoghan > > [1] > > http://svn.apache.org/viewvc/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intents/intent-map.xml?view=co > [2] > > http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/WSAddressingFeature.java?view=co > [3] > > http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/NamespaceHandler.java?view=co > [4] > > http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/AddressingBeanDefinitionParser.java?view=co > > 2009/6/18 Josh Holtzman <[email protected]> > > > I'm trying to figure out how best to apply aspects like authentication > and > > authorization to my distributed OSGi services using CXF. Since I won't > > know > > which services are deployed locally or remotely until the osgi container > is > > running, I don't think servlet filters are the right approach (the filter > > would be bypassed for local service invocations). > > > > I'm pretty sure that each service that is exposed as a remote endpoint > via > > DOSGI has its own CXF Bus. So I should be able to add interceptors to > the > > buses generated by the CXFNonSpringServlets. But I think these buses are > > bypassed when the service is locally invoked, so the CXF interceptor > > approach doesn't work either. > > > > Does anyone have suggestions for applying aspects to (D)OSGI services? > I'm > > about to read up on the new Find hooks available in the osgi 4.2 spec, > > since > > I might be able to sneak a proxy into service location, but I don't want > to > > give up on a CXF based solution if there is one. > > > > Thanks, > > Josh > > >
