L.S., That sounds like a good combination of goals to set for the next release: useability (docs, blueprint, ...) and scalability.
Perhaps we could add support for Spring 3.0 to the list -- I think Camel is already good to go there and if we move to blueprint anyway, the effort for adding that shouldn't be too big anyway, I guess... Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 17 May 2010 12:39, Guillaume Nodet <[email protected]> wrote: > Here are a few thoughts I'd like to throw in for the next version of > ServiceMix: > * documentation (we really, really need that) > * better support for Blueprint: we should support blueprint for everyhting > we have, it would include Camel, ActiveMQ and ServiceMix components > * better scalability: > - we need to put back the asynchronous support for Camel (in camel JBI > and NMR transports) > - we need to improve CXF-BC to better support streaming (the > useJbiWrapper on the consumer could still use streaming as done in > servicemix-http soap endpoints) > - we need to find a real nice http client to have non blocking threads > and where we would be able to write to the stream instead of having to give > it an input stream > > I'll try to improve the doc on karaf and move it into a docbook format for > easier integration into the servicemix doc, i think that would help too. > I'll work on the Blueprint stuff, as I've already started. > Claus is putting back async support in Camel, so once it's done, we should > be able to put back the change we reverted for upgrading to 2.0 in both JBI > and NMR compoennts for camel. > CXF-BC I think still needs some work from a scalability / performance point > of view. Having an HTTP client that could really be leveraged would be > awesome, but I don't know any that would really work yet. I think > httpcomponents may be a good candidate as it should be able to be used in > asynchronous and streaming mode. > > Also, I think we should try to do some perfs / load testing and have the > defaults config behave nicely, even if we need to break some compatibility > at some point. For example, having the cxf-bc consumer being asynchronous > by default would make sense to me. > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
