Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Adrian Trenaman <TRENAMAN@progress.com>
To: "'dev@cxf.apache.org'" <dev@cxf.apache.org>
Date: Wed, 29 Sep 2010 17:22:00 -0400
Subject: Re: Fun with the survey
Thread-Topic: Fun with the survey
Thread-Index: Actf+n+faaAd2qooTs+92LHGC0uEaQAIdqcA
Message-ID: 
 <9A11B172C0D51A488A82FBA47ACC899901E0A9F5CC@PSCMAIL03.bedford.progress.com>
In-Reply-To: <F97AD146-00C7-48E5-BFF1-83ABD2C91BA7@gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+1 for an osgibus!

----- Original Message -----
From: Johan Edstrom [mailto:seijoed@gmail.com]
Sent: Wednesday, September 29, 2010 01:19 PM=0A=
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?
>>=20
>> Well, this is something I keep thinking about quite a lot latetly.   The=
re are
>> several areas where we use Spring and expose spring to the user:
>>=20
>>=20
>> 1) Wiring our own bus together
>>=20
>> 2) Providing configuration and namespace handlers and such for the user =
to
>> more easily use CXF with spring
>>=20
>> 3) Using/abusing the spring aop stuff for things like transactions and
>> sessions scopes and such
>>=20
>> 4) JMS transport
>>=20
>>=20
>> 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.
>>=20
>> For #3, we do provide some factories for some of the scopes and such, bu=
t
>> again, spring does much of that so much better.
>>=20
>> 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.
>>=20
>> That really leaves #1.  We DO provide a non-spring version of the bus (T=
he
>> ExtensionBus stuff), but it has a bunch of limitations in what it can pi=
ck 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 modul=
es can
>> be relatively independent bundles that an "OSGIBus" could grab via tha O=
SGi
>> registries and such.    Yea.  Brain is noodling, but hasn't gotten very =
far
>> yet.
>>=20
>=20
> +1 for the OSGiBus idea, I saw lots of customer issues about using a wron=
g bus configurations in OSGi. We could do some work to make life easier :)
>=20
> --=20
> Willem
> ----------------------------------
> Open Source Integration: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: http://twitter.com/willemjiang

Johan Edstrom

joed@opennms.org

They that can give up essential liberty to purchase a little temporary safe=
ty, deserve neither liberty nor safety.

Benjamin Franklin, Historical Review of Pennsylvania, 1759