cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Fun with the survey
Date Wed, 29 Sep 2010 22:28:52 GMT
  I really like the osgi concept of services. So I think we could simply 
register services for e.g. the bindings and transports in osgi.
For non osgi environments we could create a simple service registry that 
serves the same purpose. Camel has the concept of a registry that can be
implemented using spring or without spring. That probably serves pretty 
much the same purpose. So perhaps we could create something like this.

The nice thing about osgi services is that you donĀ“t need a special 
concept like an extensionmanagerbus. You simply register services that 
implement for example
an interface ConduitInitiator  and then you can simply lookup all of 
these or even have properties to refine a search.

Any thoughts about that?

Thanks

  Christian

Am 29.09.2010 23:32, schrieb Daniel Kulp:
> Just to clarify (since I think I may have generated too much excitement around
> this)... :-)
>
> My thought are more around "fixing" the current ExtensionManagerBus to get all
> the features working properly with the extension mechanism that is currently
> in place.   When that works, creating a new implementation of ExtensionManager
> that would lookup in the OSGi registry  the various extensions should be
> relatively easy.     Thus, it's not so much an "OSGIBus" as it is making the
> ExtensionManagerBus something more usable, which would include in an OSGi
> environment.
>
> Longer term, we could then substitute the SpringBus stuff with a new
> SpringExtensionManager or similar and pretty much get down to one bus, with a
> couple of managers.   It would hopefully simplify things a bit.  We don't
> really need 3 bus implementations.  :-)
>
> Make sense?
>
> Dan
>
>
>
> On Wednesday 29 September 2010 5:22:00 pm Adrian Trenaman wrote:
>> +1 for an osgibus!
>>
>> ----- Original Message -----
>> From: Johan Edstrom [mailto:seijoed@gmail.com]
>> Sent: Wednesday, September 29, 2010 01:19 PM
>> To: dev@cxf.apache.org<dev@cxf.apache.org>
>> Subject: Re: Fun with the survey
>>
>> +1 on an osgibus, that would be great.
>>
>> On Sep 28, 2010, at 8:10 PM, Willem Jiang wrote:
>>> On 9/29/10 4:06 AM, Daniel Kulp wrote:
>>>> On Monday 27 September 2010 9:44:25 pm Benson Margulies wrote:
>>>>> It looks like our close and personal relationship with Spring
>>>>> continues to really inconvenience very few and serve the majority. I
>>>>> wonder if we would want to invest energy in merely designing some
>>>>> scheme to make Spring more removable to assist some volunteer in
>>>>> working on it?
>>>> Well, this is something I keep thinking about quite a lot latetly.
>>>> There are several areas where we use Spring and expose spring to the
>>>> user:
>>>>
>>>>
>>>> 1) Wiring our own bus together
>>>>
>>>> 2) Providing configuration and namespace handlers and such for the user
>>>> to more easily use CXF with spring
>>>>
>>>> 3) Using/abusing the spring aop stuff for things like transactions and
>>>> sessions scopes and such
>>>>
>>>> 4) JMS transport
>>>>
>>>>
>>>> I really don't want to touch on #4.  Even the JMS guys say Spring JMS is
>>>> the way to go to get JMS done correctly.
>>>>
>>>> For #3, we do provide some factories for some of the scopes and such,
>>>> but again, spring does much of that so much better.
>>>>
>>>> Everything done for #2 there are good API's (that the spring things
>>>> call) and thus can be done programatically.   If someone has a
>>>> different config mechanism, it's not hard to create a new one.
>>>>
>>>> That really leaves #1.  We DO provide a non-spring version of the bus
>>>> (The ExtensionBus stuff), but it has a bunch of limitations in what it
>>>> can pick up and wire together and such.  Much of the SecPolicy stuff
>>>> won't work for example.   This is something I was THINKING about
>>>> looking at more for 2.4, partially to make things much more OSGi
>>>> friendly where the various modules can be relatively independent
>>>> bundles that an "OSGIBus" could grab via tha OSGi registries and such.
>>>>    Yea.  Brain is noodling, but hasn't gotten very far yet.
>>> +1 for the OSGiBus idea, I saw lots of customer issues about using a
>>> wrong bus configurations in OSGi. We could do some work to make life
>>> easier :)
>> Johan Edstrom
>>
>> joed@opennms.org
>>
>> They that can give up essential liberty to purchase a little temporary
>> safety, deserve neither liberty nor safety.
>>
>> Benjamin Franklin, Historical Review of Pennsylvania, 1759

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


Mime
View raw message