cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <>
Subject Re: Concerns about the Camel / CXF documentation
Date Thu, 28 Aug 2008 12:34:36 GMT

-1 to decommissioning the CXF JMS transport.

If there are perceived shortcomings in the CXF JMS transport config, 
lets identify these issues, raise corresponding JIRAs, and get them fixed.


Benson Margulies wrote:
> My question is dumber. If Camel, a part of Apache, is a superior
> comestible for this purpose, should we consider decommissioning or
> deprecating the existing CXF JMS in favor of just using it?
> On Thu, Aug 28, 2008 at 6:15 AM, Christian Schneider
> <> wrote:
>> Glen Mazza schrieb:
>>> Christian,
>>> I have a few concerns about your write up on using Camel as a JMS
>>> alternative with CXF[1]:
>>> 1.)  I don't understand why you are duplicating your blog entry on a CXF
>>> confluence page.  Can't you just keep your blog entry up-to-date with your
>>> link to it from our articles[2] page (and perhaps a few sentences on our
>>> JMS
>>> page linking to it, for those who miss the articles page)?  Your article
>>> looks nicer on your blog anyway than it does with Confluence formatting.
>> Hi Glen,
>> I also use confluence on my blog. So the duplication effort is at least
>> quite small. The reason why I duplicated the content is that I on the one
>> hand wanted
>> to really contribute the article to cxf so anyone on the wiki can improve it
>> later. On the other hand I wanted to establish my blog. If I only wrote the
>> article on my
>> blog no one would be able to do modifications beside myself. If I only had
>> written the article on the Wiki I could not establish my blog. Shame on me
>> for using CXF for this ;-) I can cut the link if you think it is inadequate.
>> Btw. if the article looks nicer on my blog we could perhaps improve the
>> design of the cxf confluence pages ;-)
>>> 2.)  The quality of the writing on the Confluence page is not very
>>> clean--it
>>> hasn't been spell-checked, capitalization is frequently off ("apache
>>> camel"
>>> instead of "Apache Camel"), detracting from the CXF documentation as a
>>> whole, and the tone reads too informally.  Also, you have too many
>>> references to specific developers and regular usage of the first-person
>>> "I"--it is written like a blog entry instead of actual system
>>> documentation. We really don't have time to be cleaning this documentation
>>> up, you need to
>>> proofread more carefully.
>> That´s why I started the article on my blog and announced it on the mailing
>> list. I hoped that some of these problems would be found before I added the
>> article to the wiki.
>> But I got no response on the list so I added the article a day later. I will
>> try to improve the style and naming schemes today if that is ok.
>>> I write blog entries and link them to the articles page, and I also update
>>> the CXF system documentation (sometimes linking to a blog entry, either
>>> mine
>>> or others).  But the writing styles are different, and the types of things
>>> you include are different.  In particular, you are tying your Confluence
>>> article too much to yourself, but Confluence pages are for any team member
>>> to edit, and are normally written without reference to any particular
>>> author.
>> Thanks for the hints about the style. I will try to do this better in the
>> future. Perhaps it is a good idea to
>> write a howto on the project page in a neutral style. Then I could pack an
>> announcement to the howto together with my personal opinions on my blog in a
>> personal style. So the two
>> would be separated nicely. I think I still have to learn a bit aboutt
>> blogging ;-)
>>> 3.)  The tone of the documentation would appear to make it a better
>>> candidate on the Camel site rather than the CXF one, for two reasons.
>>>  (And
>>> I'm sure James Strachan would be happy to give you a place to write
>>> articles.)  For one thing, the criticisms of the CXF product, as in your
>>> entry paragraphs, is unnatural within CXF documentation.
>> You are right. I think it would be better to add the Howto to the Camel site
>> and link it from CXF Howtos. I can move the article.
>> The problem with the current Camel site is that you almost do not find the
>> Camel CXF Transport although it is
>> the better solution than the CXF component. For me the main idea behind
>> publishing this article was that I had many problems configuring
>> JMS for CXF and that the Camel integration really helped. So I hope to help
>> others with configuring JMS. If I would only add the article to the Camel
>> Wiki
>> the CXF users who do not need Camel but have problems with JMS would not
>> find it.
>> As a second intention I would like to help improve the CXF JMS config and
>> hope that the style Camel uses can be a good pattern for an improved native
>> JMS
>> config for CXF.
>>> Quote:  "Configuring JMS in Apache CXF is possible but not really easy or
>>> nice. This article shows how to use Apache Camel to provide a better JMS
>>> Transport for CXF...JMS configuration in Apache CXF is possible but the
>>> configuration is not very flexible and quite error prone. In CXF you have
>>> to
>>> configure a JMSConduit or a JMSDestination for each webservice. The
>>> connection between Conduit and the Service proxy is the endpoint name
>>> which
>>> looks like "{http://service.test\}HelloWorldPort.jms-conduit". As this
>>> name
>>> is never explicitly configured elsewhere it is quite probable that you
>>> misspell the name. If this happens then the JMS Transport just does not
>>> work. There is no good error reporting to show you what you did wrong."
>>> Pointing out the minuses of a software product, such as CXF, is perfectly
>>> acceptable, but not on the CXF's product's page itself--this should with
>>> the
>>> Camel project, where you are explaining an alternative.  That's where you
>>> establish the contrast, the criticisms that you're finding with CXF.
>>>  While
>>> you can still link to alternative and better solutions from the CXF site
>>> (and even say they're better), the self-criticism part directly within the
>>> system documentation seems strange.
>> As mentioned above I hope to help people with JMS problems in the short run
>> and help improve CXF JMS
>> in the long run. Sorry if this criticism is too harsh. Perhaps it suites
>> better when I place the article on the Camel wiki.
>> I can also try to be a little less harsh in the criticism. The only reason
>> why I wrote this passage anyway was to motivate
>> why you should use a separate product to configure CXF JMS. My intention is
>> in no way to move people to Camel or something.
>> I only hope to help the users of CXF and improve CXF.
>>> For example, if I want to suggest where Maven is better than Apache Ant
>>> for
>>> building software, those technical articles (and legitimate criticisms) go
>>> on the Maven website ("Apache Ant is good for many things, but falls short
>>> in these project-building aspects...), not on the Ant website.  It is
>>> unusual to ask team members to maintain documentation criticizing their
>>> project.  For the second reason, Camel embeds CXF--not vice-versa; for
>>> that reason,
>>> perhaps placement on the Camel site would appear more appropriate, with
>>> just
>>> links from CXF.
>> I understand. So moving the article to Camel is a good idea. Is it ok to
>> link to the Camel article from the Wiki though?
>> Btw. What do you think about improving the JMS config for CXF? Would you
>> think the style from Camel I showed is good? I really like
>> the idea to choose the JMS connection in the address rather than in a
>> separate conduit definition. I also think it´s great to use Spring
>> internally to
>> make use of their transaction management. The last thing I liked is
>> refrencing the ConnectionFactory as a bean.
>> Best regards
>> Christian
>> --
>> Christian Schneider
>> ---

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
View raw message