Concerns about the Camel / CXF documentation

[Glen Mazza <gl...@gmail.com>]

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.

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.

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.

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.

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.

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.

Regards,
Glen

[1] http://tinyurl.com/57ol4h
[2] http://cwiki.apache.org/confluence/display/CXF/Resources+and+Articles

-- 
View this message in context: http://www.nabble.com/Concerns-about-the-Camel---CXF-documentation-tp19194940p19194940.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Concerns about the Camel / CXF documentation

[Willem Jiang <wi...@gmail.com>]

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 <eo...@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
>>> <ch...@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
>>
>>     
>
>   

Re: Concerns about the Camel / CXF documentation

[Bharath Ganesh <bh...@gmail.com>]

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 <eo...@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
>> <ch...@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
>

Re: Concerns about the Camel / CXF documentation

[Eoghan Glynn <eo...@iona.com>]

-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
> <ch...@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

Re: Concerns about the Camel / CXF documentation

[Daniel Kulp <dk...@apache.org>]

On Thursday 28 August 2008 8:26:58 am 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?

No, I definitely wouldn't go that route.    We definitely should get our JMS 
transport fixed up a bit to be more usable.   

There are two areas that really need addressing:

1) The Spring integration to use the standard spring JMS configuration 
constructs

2) SOAP over JMS spec
http://www.w3.org/Submission/SOAPJMS/

That's the slightly trickier one as it would require the URL to be a "jms:" 
url and not a "camel:" url.  It's also going to require a bit more 
interaction with the rest of CXF to make sure all the JMS headers are set 
right, etc....

Because of (2), it's definitely something we would want to be shipping with 
CXF.   I really would prefer not using the Camel one as that introduces a 
bunch of dependencies as well as causes a circular dependency between 
projects, which always sucks.

Dan



> On Thu, Aug 28, 2008 at 6:15 AM, Christian Schneider
>
> <ch...@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



-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Concerns about the Camel / CXF documentation

[Christian Schneider <ch...@die-schneider.net>]

Benson Margulies schrieb:
> 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
> <ch...@die-schneider.net> wrote:
>   
I think it would be bad idea to simply use Camel as is as a JMS 
transport replacement for CXF in the long run. Camel and CXF have 
different object models for example for Messages and Exchanges.
So when a CXF Exchange crosses the border to Camel it has to be 
converted. Additionally you get a lot more dependencies when you add 
Camel to your stack.

So for me there are two different possibilities to improve CXF JMS.

The first is to rewrite the JMS code for CXF. The camel JMS 
implementation can be a good starting point for this but it would mean a 
separate code base from Camel.

The other possibility is to base Camel and CXF perhaps even also 
Servicemix on a common kernel of Objects like Message and Exchange. Then 
there could also be a common codebase for Transports that can then be 
used for all these projects. Perhaps Servicemix kernel could be this 
common base but I do not know enough about it to be sure.

What way is the better depends on two things the goals of the projects 
and how well the teams can depend on each other. If the goals are quite 
common and the teams work well together then the second way is the 
better else it is better to keep the codebases separate. But that´s only 
my two cents ;-)

Best regards

Christian

Re: Concerns about the Camel / CXF documentation

[Benson Margulies <bi...@gmail.com>]

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
<ch...@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
>
>

Re: Concerns about the Camel / CXF documentation

[Christian Schneider <ch...@die-schneider.net>]

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