cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Advanced Configuration in DOSGI
Date Thu, 14 Oct 2010 12:11:05 GMT
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.bosschaert@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 <sberyozkin@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
>>
>

Mime
View raw message