You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2010/09/28 03:44:25 UTC
Fun with the survey
I finally got around to reading the survey.
I have a few observations about the obvious. We love jetty. Our users
do not. Our users love tomcat. We do not. One might feel motivated to
shift tests to tomcat, or add tests with tomcat ... except that we
don't get a lot of JIRum on plain tomcat.
The survey, on the other hand, reiterates the high pain level
associated with the big app servers that make it hard to get the
classpath right for CXF. I have no idea if we can do anything except
write more documentation.
More documentation would certainly be appreciated.
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?
There are some WS-*'s that would make an impression.
Java-first issues sure attract the vocal if not the numerous.
Re: Fun with the survey
Posted by Johan Edstrom <se...@gmail.com>.
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:seijoed@gmail.com]
>> Sent: Wednesday, September 29, 2010 01:19 PM
>> To: dev@cxf.apache.org <de...@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
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
Re: Fun with the survey
Posted by Daniel Kulp <dk...@apache.org>.
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<de...@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
Re: Fun with the survey
Posted by Christian Schneider <ch...@die-schneider.net>.
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<de...@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
AW: Fun with the survey
Posted by Oliver Wulff <ol...@sopera.com>.
+1 for simplified OSGI integration
Oli
________________________________________
Von: Guillaume Sauthier [Guillaume.Sauthier@objectweb.org]
Gesendet: Donnerstag, 30. September 2010 09:26
An: dev@cxf.apache.org
Betreff: Re: Fun with the survey
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:seijoed@gmail.com]
>>> Sent: Wednesday, September 29, 2010 01:19 PM
>>> To: dev@cxf.apache.org<de...@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
>>
>
>
Re: Fun with the survey
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
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:seijoed@gmail.com]
>>> Sent: Wednesday, September 29, 2010 01:19 PM
>>> To: dev@cxf.apache.org<de...@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
>>
>
>
Re: Fun with the survey
Posted by Willem Jiang <wi...@gmail.com>.
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:seijoed@gmail.com]
>> Sent: Wednesday, September 29, 2010 01:19 PM
>> To: dev@cxf.apache.org<de...@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
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: Fun with the survey
Posted by Daniel Kulp <dk...@apache.org>.
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 <de...@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
Re: Fun with the survey
Posted by Adrian Trenaman <TR...@progress.com>.
+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 <de...@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 :)
>
> --
> 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 safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: Fun with the survey
Posted by Johan Edstrom <se...@gmail.com>.
+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 :)
>
> --
> 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 safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: Fun with the survey
Posted by Willem Jiang <wi...@gmail.com>.
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 :)
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: Fun with the survey
Posted by Daniel Kulp <dk...@apache.org>.
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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Fun with the survey
Posted by Johan Edstrom <se...@gmail.com>.
I'm one of the ones passionately hating spring-dm.
I'd be very very very happy to remove spring.
I'd also be more than happy to remove spring since it has gone from
"Hey this is great for devs" to let us re-invent every wheel out there.
Count me in.
/je
On Sep 27, 2010, at 7:44 PM, Benson Margulies wrote:
> I finally got around to reading the survey.
>
> I have a few observations about the obvious. We love jetty. Our users
> do not. Our users love tomcat. We do not. One might feel motivated to
> shift tests to tomcat, or add tests with tomcat ... except that we
> don't get a lot of JIRum on plain tomcat.
>
> The survey, on the other hand, reiterates the high pain level
> associated with the big app servers that make it hard to get the
> classpath right for CXF. I have no idea if we can do anything except
> write more documentation.
>
> More documentation would certainly be appreciated.
>
> 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?
>
> There are some WS-*'s that would make an impression.
>
> Java-first issues sure attract the vocal if not the numerous.
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
Re: Fun with the survey
Posted by Christian Schneider <ch...@die-schneider.net>.
A regular scheme at companies that I have seen is running the tests in
Jetty and the production system on tomcat.
So I guess having the test in Jetty is some kind of best practice even
when tomcat is used later.
Trying to remove spring is something that many frameworks try nowadays.
The problem is that this usually means that they
code their own di stack. I don´t think that makes life much easier in
the end. If we manage to replace spring by something very simple
that works in pure java that would be a good idea. I can not judge
though how feasible this is.
Regards
Christian
Am 28.09.2010 03:44, schrieb Benson Margulies:
> I finally got around to reading the survey.
>
> I have a few observations about the obvious. We love jetty. Our users
> do not. Our users love tomcat. We do not. One might feel motivated to
> shift tests to tomcat, or add tests with tomcat ... except that we
> don't get a lot of JIRum on plain tomcat.
>
> The survey, on the other hand, reiterates the high pain level
> associated with the big app servers that make it hard to get the
> classpath right for CXF. I have no idea if we can do anything except
> write more documentation.
>
> More documentation would certainly be appreciated.
>
> 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?
>
> There are some WS-*'s that would make an impression.
>
> Java-first issues sure attract the vocal if not the numerous.
>
--
----
http://www.liquid-reality.de