Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Sender: Christian Schneider <cschneider111@gmail.com>
Subject: Re: CXF cross cutting concerns
To: users@camel.apache.org
References: <1457537164834-5778798.post@n5.nabble.com>
 <CAKoNANuxi-ztp5+MMO0UcKyYqf=W-NjAA-MkVTsOvnz6Yw-HqQ@mail.gmail.com>
From: Christian Schneider <chris@die-schneider.net>
Message-ID: <56E80496.8020407@die-schneider.net>
Date: Tue, 15 Mar 2016 13:48:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAKoNANuxi-ztp5+MMO0UcKyYqf=W-NjAA-MkVTsOvnz6Yw-HqQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Changing the already posted busses is not such a good idea.

The CXF DOSGi way is to use intents. You can publish a feature as a 
service and give it a property org.apache.cxf.dosgi.IntentName=myname.
In the OSGi service to be exported you can then set the property 
service.exported.intents to a list of intent names that must be supported
to export this service.

CXF DOSGi will then make sure it finds suitable intent services and will 
apply them as features before exporting your service.

Christian

On 14.03.2016 21:52, Raul Kripalani wrote:
> Hi
>
> I blogged about this a long while ago. CXF registers all buses as OSGi
> services, so you can create a service listener that watches them come and
> go, reacting accordingly. You do get a reference to the bus, so you can add
> interceptors, features or change whatever configuration you'd like to by
> finding your way around the API.
>
> Have a look at
> http://raul.io/enriching-services-with-cxf-interceptors-in-osgi/, and let
> me know if it helped.
>
> Cheers,
> Raúl.
> On 9 Mar 2016 15:26, "Ranx" <brad.johnson@mediadriver.com> wrote:
>
>> I have a client who wants to use deployable microservice bundles with
>> REST/SOAP APIs.  Not a problem of course as it works very well.
>>
>> The issue is that I'm getting a lot of boilerplate replication across the
>> project which is only getting to get bigger and more difficult to manage
>> with time.
>>
>> This includes everything from basic host/port settings to security.
>> Obviously setting that up in every bundles is error prone (especially with
>> XML) and the a real headache for maintenance.  Part of the problem is that
>> from what I've read sharing cfg files across bundles is not recommended.
>> Perhaps with an update strategy reload that isn't such a big deal.  But it
>> would be nice to have something like:
>>
>> com.foo.basic.rest.cfg
>> com.foo.basic.soap.cfg
>>
>> and use that in each of my bundles to load basic configuration information.
>> Each bundle would still have its own cfg file that will be used for very
>> special and custom items.
>>
>> Things like PasswordCallback and keystores are exactly the same.  In the
>> past I've always used a gateway bundle to centralize that.  I may still end
>> up using something like that in this project but as "microservices" become
>> more and more the holy grail (until it isn't anymore) this is going to be
>> an
>> on-going concern.
>>
>> I'm using Karaf so can also imagine using OSGi registry for creating CXF
>> interceptors that I might inject into the setup of each of my projects.
>>
>> This problem is manifesting on the endpoints in both directions.  For
>> example, one of the systems I'm integrating with is JDEdwards SOAP services
>> which require PasswordCallbacks and http conduit settings.  But there are a
>> large number of these services with WSDLs for many aspects of inventory,
>> supply, invoices, etc.
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/CXF-cross-cutting-concerns-tp5778798.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com