cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: Concerns about the Camel / CXF documentation
Date Thu, 28 Aug 2008 13:44:00 GMT
We could do some improvement on the CXF JMS transport base on camel-jms 
codes.

I also saw some requirement about using spring JMS template to implement 
the CXF JMS transport API.

Willem

Bharath Ganesh wrote:
> I can work on this. Let me get started by setting up the CXF JMS transport
> and play a bit with it.
>
> On Thu, Aug 28, 2008 at 6:04 PM, Eoghan Glynn <eoghan.glynn@iona.com> wrote:
>
>   
>> -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.
>>
>> /Eoghan
>>
>>
>> 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
>>> <chris@die-schneider.net> 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
>>>> ---
>>>> http://www.liquid-reality.de
>>>>
>>>>
>>>>
>>>>         
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>
>>     
>
>   


Mime
View raw message