Hi Fabio, You are right that the service.intents, service.exported.intents and service.exported.intents.extra are all merged on the distributed discovery information. These properties do serve different purposes, however.
On the service provider side: * service.intents: indicates any intents that are implemented by the service's logic itself. Maybe the service encrypts the message before it leaves the API or something like that. * service.exported.intents: any intents specified in this property have to be provided by the OSGi Remote Services implementation and intents specified in this property are crucial to the semantics of the service. Transactionality could be an example. If the Remote Services implementation can not provide these intents it must not export the service. * service.exported.intents.extra: these are also intents that need to be provided by the OSGi Remote Service implementation, but they are used to configure the distributed service. The internal semantics of the service don't depend on these intents but the working of the system does. These intents should really be made configurable from the outside (e.g. through config admin). An example could be a secure protocol setup. Again, if the OSGi Remote Service implementation cannot provide these intents the service must not be exported. For more information see [1]. Typically you will find that the intents that a OSGi Remote Service implementation provide are configurable. In the case of CXF-DOSGi this is currently done through the intent-map.xml... On the service consumer side, the consumer wants to see all the intents that are provided by the remote service. At that point it doesn't matter where they came from that's why they are merged into a single service.intents property from the client view. BTW all the information present in a distributed discovery system (actuallt in the EndpointDescription [2]) represents the service consumer view so it therefore doesn't contain any 'exported' properties. However you should see some *.imported properties there... Hope this helps, David [1] Table 13.1 in the OSGI 4.2 Enterprise Specification http://www.osgi.org/Download/Release4V42 [2] http://www.osgi.org/javadoc/r4v42/org/osgi/service/remoteserviceadmin/EndpointDescription.html On 15 October 2010 17:07, Fabio souza <[email protected]> wrote: > Hi, > > Looking at DOSGi's intents implementation I found something that seems > a little bit strange to me... To apply an intent during proxy > creation, the method createProxy in class PojoConfigurationTypeHandler > calls method applyIntents, right? Ok, but, this method calls > getRequestedIntents to recover the intents that should be applied. > However, this last method looks for intents using something like: > > Collection<String> intents = Arrays.asList( > OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, > RemoteConstants.SERVICE_EXPORTED_INTENTS))); > Collection<String> extraIntents = Arrays.asList( > OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, > RemoteConstants.SERVICE_EXPORTED_INTENTS_EXTRA))); > Collection<String> oldIntents = Arrays.asList( > OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, > Constants.EXPORTED_INTENTS_OLD))); > > Set<String> allIntents = new HashSet<String>(intents.size() + > extraIntents.size() + oldIntents.size()); > allIntents.addAll(intents); > allIntents.addAll(extraIntents); > allIntents.addAll(oldIntents); > > However, in CXF-DOSGi, when SERVICE_EXPORTED_INTENTS and > SERVICE_EXPORTED_INTENTS_EXTRA are copied to ZooKeeper they are > combined in a property named service.intents. So, there aren't > properties named *EXPORTED* on the proxy side and this code doesn't > find any intents to apply... So, I guess that in that version I can > use intents that are supposed to include interceptors in the proxy > side. Am I right? > > Thank you, very much! > > Cheers, > > Fábio >
