Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.214.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=MHmJ/jHRflGzmlUWeWoAkGIoAwmtZPsfng0Qa0oOP/aywQc2vDTDtgMcKjVZ1vHOQU
         fYFmy4GVyQ0q1q1Z9OA79jHJKTF4lLpem6OSxjsbSCyo2ZtnrLTQnk05oqcI/sAApylT
         qMDk6/hNCKWsDDCuRdwPOSuJ/RI8KiGJZiiSk=
MIME-Version: 1.0
Date: Thu, 14 Oct 2010 12:36:49 +0100
Message-ID: <AANLkTim5Xd9xZkQhPaudQuN0aLBpo=uYPhqz6GAhuk=2@mail.gmail.com>
Subject: Advanced Configuration in DOSGI
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=00504502de262ea2b904929220d8

--00504502de262ea2b904929220d8
Content-Type: text/plain; charset=ISO-8859-1

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

--00504502de262ea2b904929220d8--