cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <>
Subject Re: [DISCUSS?] XFire compat
Date Tue, 16 Sep 2008 00:30:12 GMT

My $0.02: XFire and CXF are different web stacks, we don't need to import
anything from them, unless IONA or another supporting company has a business
need to work with XFire.  XFire is basically yesterday's news, and as for
web service stack incompatibilities--they exist between all web service
stacks anyway, even CXF and Metro.

If we were to say that CXF, by virtue of the fact that a few years ago it
was based on XFire, needs to still be saddled with that product now and
forever more, then we would be putting CXF at a disadvantage of other
products, which, blessed with not having anything to do with XFire, can
concentrate on moving forward with more modern[1] concerns.

OTOH, if there are *small* changes that could bring in lots of XFire users,
sure, that would be a good idea.  It's really a cost-benefit issue on each
change.  Another concern is that developers, whether paid or volunteer,
cannot generally afford to work with yesterday's technologies--we don't want
two-week notices from anyone or dropped volunteers as a result of saddling
people with maintaining yesterday's stuff.



Benson Margulies-4 wrote:
> I am queasy about adding code to CXF that enables, even optionally,
> XFire 'bug-for-bug' compatibility. Somehow, it feels like a bad thing
> to enable/encourage the deployment of code that purports to conform to
> a standard but does not. A service configuration that warps the JAX-WS
> behavior, for example. What do other people thing?

View this message in context:
Sent from the cxf-dev mailing list archive at

View raw message