Hi Sergey, I see nothing wrong with "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml"
but am wondering, why could you not to do this "service.exported.intents.extra" : "http_proxy" and then put the "http_proxy" configuration in the OSGi-INF/cxf/intents/intent-map.xml file. I don't really see a fundamental difference between the two. Whether or not the client-side sees the 'http_proxy" intent on then remote service reference is pretty harmless IMHO, but you could think of a mechanism to filter out certain intents from the remote publication if this is absolutely needed. Note that I'm using service.exported.intents.extra instead of service.exported.intents. Although the values of these properties get merged at runtime they serve different purposes. service.exported.intents is for intents that are crucial to the *behaviour* of the service. For instance the fact that a transaction context is available. service.exported.intents.extra is for additional configuration that might be needed for some users, and proxy configuration is a perfect example of that. The idea is that developers who use these properties would make the service.exported.intents.extra property configurable externally, e.g. through Configuration Admin or some other mechanism (see [1] for more information). Just my thoughts, David [1] Table 13.1 in the OSGi 4.2 Enterprise Release (http://www.osgi.org/Download/Release4V42) On 14 October 2010 12:36, Sergey Beryozkin <[email protected]> wrote: > Hi > > DOSGI (RI) offers two options for users to configure the providers and > consumers > > 1. Intents - short policy-like statements > 2. Properties > > In some cases these options may not be sufficient. > For example, consider a requirement to configure a DOSGI consumer with TLS > properties or HTTP proxy properties. > > Templated intents might be used in principle - however it seems a difficult > thing to achieve. > Ex, on the server side, the DOSGI would need to figure out which individual > properties needs to be blocked from the publication (ex, the location of the > key store, etc). Application bundles would need to import concrete > implementations of such templated intents and depend on DOSGI RI. Also I'm > not sure if intents can be used for a pure client-side configuration (ex, > http proxies). Finally, perhaps intents are not really usable for some > low-level configuration or customization. > > Properties may always be used - but this is problematic for two reasons. In > complex cases we may have a lot of complex properties. Of more concern to me > is that we currently have not agreed on using a shared set of properties for > SOAP and REST services thus we'd have many duplicated properties for say > configuring HTTPS or HTTP proxies for either SOAP clients or proxy-based > JAXRS clients. > > So one way here is to figure out how to let users configure easily consumers > to work with HTTP proxies. Here is the concrete example taken from the > recent email on the users list : > > <http-conf:client ProxyServer="1.2.3.4" ProxyServerPort="80" > ProxyServerType="SOCKS" /> > <http-conf:proxyAuthorization> > <UserName>asdf</UserName> > <Password>qwer</Password> > </http-conf: > proxyAuthorization> > > lets try to figure out how we can configure in DOSGI. > > One option is to let users just reuse such configurations. > > So here's one concrete proposal. > > Introduce "org.apache.cxf.ws/rs.external.config" (or similar). > Ex, > > "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml" > > > Thus users will be able to reuse some existing configuration which they may > also be relying upon in non-DOSGI environments but they will use the DOSGI > properties mechanism (at the cost of introducing one extra property per > ws/rs) to bootstrap those existing CXF config beans. > > Comments, any other ideas ? > > thanks, Sergey >
