Sergey Beryozkin-5 wrote: > > Let me put it the other way. I haven't started this thread to complain > about > Spring, or start any debate about the use of Spring. What I'd like to > convey > is that IMHO it is in the interests of CXF to ensure that those > integrators > who prefer to provide non-Spring deployments can do it as easily as > possible. >
Yes, but be careful. When you say "non-Spring deployment", you are really saying "non-standardized framework deployment", because to generalize your concern, you are trying to satisfy a user who does not want *any* external framework libraries to be used within CXF. As I was trying to imply with Banana, once you switch to that framework the user is going to want us to get rid of that as well, so I think it would be better to generalize your scenario to that of a user who wants us to roll our own framework (i.e., like Metro) rather than rely on one that well tested and understood by a multitude of developers. I would certainly agree with disconnecting from Spring (indeed any external library) where the JDK already offers equivalent OOTB functionality, or where it just takes a few lines of code to separate from the third party library. But I would careful about reinventing the wheel and duplicating significant amounts of code internally just so we can say that we're Spring-free. A strong case can be made for code reuse and relying on frameworks rather than having each project invent and maintain its own--and for everyone happy that we've moved from org.springframework.* to org.cxf.*, several more would be concerned about our move to a lesser-used and -tested internal framework. Glen -- View this message in context: http://cxf.547215.n5.nabble.com/JMS-transport-strongly-depends-on-Spring-tp2262704p2264830.html Sent from the cxf-dev mailing list archive at Nabble.com.
