cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Fun with the survey
Date Thu, 30 Sep 2010 15:16:42 GMT
On Wednesday 29 September 2010 6:28:52 pm Christian Schneider wrote:
>   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. 

That's really all the Bus is.  It's really completely misnamed.   The Bus 
really just provides 3 things:

1) Registry of registries - all of the XXXXXManagers are stuck on here so 
there is a place  for things to query them as needed.

2) Place for application level interceptors to be registered.  Kind of a 
"global for the app" set of interceptors.   Logging is common at this level.

3) Place for application level properties.  (this is relatively new.  I think 
added in 2.2.3 or somewhere there about) 


That's really all it is.  


> 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.

That's what we have today.   We have the "normal" case which results in a Bus 
that uses Spring context for lookups of services and such.   We also have the 
ExtensionManager stuff for the non-spring case.   


> 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?

That's pretty much the point of an OSGIExtensionManager for the Bus.   It 
would just look in the OSGi registry for whatever extensions it can find that 
match the criteria.

The TRICKY part is how we would/can support some of the stuff that falls on 
application level things.   For example, we currently allow setting things 
like work queue sizes and such in config and the WorkQueueManager would pick 
those up.   If the WorkQueueManager is now registered as a more "global" OSGi 
service, it may not be possible to configure those on an application level.

We may also need to modify some API's to support these better.  For example, 
right now, the ConduitInitiators hold onto the Bus they are registered on so 
that when they need to configure a conduit, they can grab the configuration 
manager thing from the bus.  (and the Bus needs to be passed to the Conduit as 
well).   That prevents a singleton ConduitInitiator (that may be registered as 
a service) from being usable with multiple buses.   Thus, various API's may 
need to be updated to have the bus passed along instead of injected in.   Not 
a BAD thing, but something we need to be aware of and it does affect various 
API's.


Dan



> 
> 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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message