I is still *excited* </borat> On Sep 29, 2010, at 3:32 PM, Daniel Kulp wrote:
> > 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:seij...@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 >> >> j...@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 > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog Johan Edstrom j...@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
