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:06:31 GMT
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