Hi
I want to propose that we remove the @author tags in the source code
for Apache Camel.
We only have about 20 files with author tags and for 2 persons.
As I understand its not common at Apache to have @author tags in the
source code.
Here is my +1 to remove them
--
Claus Ibsen
Apache Camel
On Tue, Jul 7, 2009 at 12:54 AM, Claus Ibsenclaus.ib...@gmail.com wrote:
Hi
I want to propose that we remove the @author tags in the source code
for Apache Camel.
We only have about 20 files with author tags and for 2 persons.
As I understand its not common at Apache to have @author tags in
+1 for this.
Since it's open source project, anyone can have the right to modify the
code, we should encourage people to do it :)
Willem
Claus Ibsen wrote:
Hi
I want to propose that we remove the @author tags in the source code
for Apache Camel.
We only have about 20 files with author tags
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the xxxDefinition classes provide a
toString() method which presents a DSL-style string, the rendering work will
be much easier. If it is determined, I will do this work.
Claus Ibsen-2
On Tue, Jul 7, 2009 at 9:57 AM, alloyerallo...@gmail.com wrote:
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the xxxDefinition classes provide a
toString() method which presents a DSL-style string, the rendering work will
be
yep, a sample is as follows:
when rendering such a DSL:
from(direct:start).filter(header(foo).isEqualTo(bar)).to(mock:result)
the from and to are easy to handle, but the filter definition
maintains a {header(foo) == bar} predicate for
(header(foo).isEqualTo(bar)).
So I have to generate the
Hi,
xxxDefinition classes has the toString() method, which is useful for
tracing the message.
I don't know if it can help your Groovy rendering.
Willem
alloyer wrote:
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the
yeah, I am now using the toString() method to render the route on some
xxxDefinitions, but I am still not sure whether the renderer can deal with
a sufficient complicated expression through this method. I am a little
worried
about the renderer's handling with some incidental interminable DSL.
camel-jms - Support jms producer with InOut using custom and dynamic JMSReplyTo
provided as header
--
Key: CAMEL-1807
URL:
[
https://issues.apache.org/activemq/browse/CAMEL-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-1807:
---
Attachment: CAMEL-1807.patch
A patch but the problem is that the affinity should be local scoped
[
https://issues.apache.org/activemq/browse/CAMEL-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-1807:
---
Fix Version/s: (was: 2.0.0)
Future
camel-jms - Support jms producer with
So yeah, rendering languages that we input as a String (i.e. XPath, EL,
etc.) is easy since we have the language text available. The toString
operations on PredicateBuilders on the other hand don't return exactly what
was used to create them. Like you mentioned, header(foo).isEqualTo(bar)
returns
On Tue, Jul 7, 2009 at 3:37 PM, Jon Ansteyjans...@gmail.com wrote:
So yeah, rendering languages that we input as a String (i.e. XPath, EL,
etc.) is easy since we have the language text available. The toString
operations on PredicateBuilders on the other hand don't return exactly what
was used
Yeah, thats probably the better option here and wouldn't be too hard to
implement. Xueqiang, does this sound good to you? Maybe a toDslString()
method or something is needed.
On Tue, Jul 7, 2009 at 11:27 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Tue, Jul 7, 2009 at 3:37 PM, Jon
file component - markerFile read lock - do not use nio FileLock
---
Key: CAMEL-1808
URL: https://issues.apache.org/activemq/browse/CAMEL-1808
Project: Apache Camel
Issue Type:
[
https://issues.apache.org/activemq/browse/CAMEL-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52721#action_52721
]
Claus Ibsen commented on CAMEL-1808:
See forum
[
https://issues.apache.org/activemq/browse/CAMEL-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-1808.
Resolution: Fixed
trunk: 791854.
file component - markerFile read lock - do not use nio
yeah, this additional method may bring improvement for my work as current
groovy renderer does some hard code to deal with the expressions.
janstey wrote:
Yeah, thats probably the better option here and wouldn't be too hard to
implement. Xueqiang, does this sound good to you? Maybe a
+1 for removing.
On Tue, Jul 7, 2009 at 3:47 AM, Willem Jiangwillem.ji...@gmail.com wrote:
+1 for this.
Since it's open source project, anyone can have the right to modify the
code, we should encourage people to do it :)
Willem
Claus Ibsen wrote:
Hi
I want to propose that we remove
Share the Jetty connector across camel context
--
Key: CAMEL-1809
URL: https://issues.apache.org/activemq/browse/CAMEL-1809
Project: Apache Camel
Issue Type: Improvement
Components:
[
https://issues.apache.org/activemq/browse/CAMEL-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-1809.
-
Resolution: Fixed
trunk
http://svn.apache.org/viewvc?rev=792038view=rev
camel 1.x branch
21 matches
Mail list logo
