Hi Sergey, Just seeing your other thread regarding making it easy to migrate existing CXF users who already have cxf.xml configuration after replying to this one. Yes - I see your point. It would make sense to easily migrate from plain CXF to DOSGi. An alternative could be to abandon the intent-map.xml altogether and allow intents to be configured in the cxf.xml file.
Cheers, David On 14 October 2010 13:06, David Bosschaert <david.bosscha...@gmail.com> wrote: > 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 <sberyoz...@gmail.com> 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 >> >
