a big +1 for OSGi friendlyness :)
--G
Le 30/09/2010 03:22, Willem Jiang a écrit :
On 9/30/10 5:32 AM, 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?
It makes sense to create a OSGiExtensionManager for
ExtensionManagerBus and SpringBus to use :)
With this ExtensionManager, I think we can make OSGiServletTransport
more easy to use which means the bus could wait the ServletTransport
Service to start, and we don't need to let the Servlet to init the
endpoints application context any more.
That is what I'm exciting about.
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
