[jira] Updated: (CAMEL-1280) RoutingSlip EIP - To support same iterators as the dynamic recipient
[ https://issues.apache.org/activemq/browse/CAMEL-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1280: --- Fix Version/s: (was: 1.5.1) 1.5.2 RoutingSlip EIP - To support same iterators as the dynamic recipient Key: CAMEL-1280 URL: https://issues.apache.org/activemq/browse/CAMEL-1280 Project: Apache Camel Issue Type: Improvement Components: camel-core Affects Versions: 1.5.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0.0, 1.5.2 Look at dynamic recipient which have documented what the header object type can be and how it resolves the destinations. Do the same for routing slip. And support createIterator with an overloaded method that accepts an uri delimiter for the Scanner Maybe some code can be shared between routing slip and recipient list -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1229) from DSL to support multiple endpoints
[
https://issues.apache.org/activemq/browse/CAMEL-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-1229:
---
Fix Version/s: (was: 1.5.1)
1.5.2
from DSL to support multiple endpoints
--
Key: CAMEL-1229
URL: https://issues.apache.org/activemq/browse/CAMEL-1229
Project: Apache Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 1.5.0
Reporter: Claus Ibsen
Fix For: 2.0.0, 1.5.2
Currently you can kinda do it in Java DSL (I dont think its possible in
Spring DSL)
{code}
from(foo).from(bar).to(log:hello)
{code}
But we should be able to do it as
{code}
from(foo, bar).to(log:hello)
{code}
Some end-users is requesting it, and he is using Spring DSL.
I created this ticket to not forget about it
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1288) Upgrade to Spring Integration 1.0.1
[ https://issues.apache.org/activemq/browse/CAMEL-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1288: --- Fix Version/s: (was: 1.5.1) 1.5.2 Upgrade to Spring Integration 1.0.1 --- Key: CAMEL-1288 URL: https://issues.apache.org/activemq/browse/CAMEL-1288 Project: Apache Camel Issue Type: Task Components: camel-spring-integration Reporter: Claus Ibsen Assignee: Willem Jiang Priority: Minor Fix For: 2.0.0, 1.5.2 Spring Integration 1.0.1 is now in central maven repo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1002) Quartz support should allow stateful jobs
[ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea reassigned CAMEL-1002: -- Assignee: Hadrian Zbarcea Quartz support should allow stateful jobs - Key: CAMEL-1002 URL: https://issues.apache.org/activemq/browse/CAMEL-1002 Project: Apache Camel Issue Type: Improvement Components: camel-quartz Affects Versions: 1.4.0 Reporter: Martin Gilday Assignee: Hadrian Zbarcea Fix For: 1.5.1, 2.0.0 Attachments: quartz.patch See http://www.nabble.com/Clustered-Quartz-td20068086s22882.html Currently Quartz only has CamelJob which implements Quartz's Job interface. There is no option to use an implemenation of StatefulJob. This causes problems when you may want to use a JDBC JobStore and have Quartz running on multiple machines, as you may end up with multiple jobs running together. StatefulJob in effect allows for a blocking singleton style job on one machine. Attached is a patch which adds a new URI parameter named stateful, which defaults to false. When set to true it uses StatefulCamelJob. One significant change to the QuartzComponent is that a reference to the CamelContext is now stored in the Quartz Scheduler. This idea is taken from Spring's SchedulerFactoryBean which stores a reference to a Spring ApplicationContext. This is needed as when using stateful jobs the URI of the Endpoint is stored instead of a reference to the endpoint. This is to allow for the use of JDBC JobStore as the URI can be serialised and shared beteen participating schedulers. Current Faults: Still has no notion of volatility Difference in operation between CamelJob and StatefulCamelJob is not strictly needed. It may be less confusing if both versions simply store the URI instead of an endpoint reference. You need to use stateful if you want to use clustering at all due to the reason above. This is mixing together clustering support and blocking functionality. In Camel 2 we may want to try rewriting this Component as it is becoming a little messy. It would be nice to try and harness the power of Spring's SchedulerFactoryBean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1216) DeadLetterChannel - allow it to be enabled for transacted exchanges as well
[ https://issues.apache.org/activemq/browse/CAMEL-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1216: --- Fix Version/s: (was: 1.5.1) DeadLetterChannel - allow it to be enabled for transacted exchanges as well --- Key: CAMEL-1216 URL: https://issues.apache.org/activemq/browse/CAMEL-1216 Project: Apache Camel Issue Type: Improvement Components: camel-core Affects Versions: 1.5.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0.0 See nabble: http://www.nabble.com/Please-keep-this-unintended-feature-in-camel-and-other-requests-td21025627s22882.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XML vs a dynamic DSL
2009/1/27 Ramon Buckland ra...@thebuckland.com: Because of the nature of moving paths (and shifting systems from dev to UAT and UAT to production) we have found using XML is good for it's flexibile change capabilities. However, I have as usual the XML has pain, that the XML's config becomes cumbersome (we have all been there). I was wondering, has anyone thought of (or is there) a dynamic form of the Java DSL .. like .. jsp's or the old jws files in Axis, which are compiled on demand. camelContext id=camel... routeBuilder resource=path/to/myrouteBuilder.crb/ /camelContext And crb is just a java source file which will get compiled and then loaded ... ?thoughts What this means is the crb (camel route builder) can be seen by application support staff, and paths modified and server restarted for changes etc .. of course .. goes without saying that I am sure groovy could be plugged in some how in the same manner (no ? ) Hello Ramon, Don't forget, that route builder is a POJO after all, so you can configure it however you like using spring. Then you just have to reference your route builder from camel context via routeBuilderRef/ element. Another solution is that you could actively pull your configuration from Spring/JNDI/... using getContext().getRegistry().lookup(name); in your configure() method, so you will configure yourself. This way you have the best from both worlds - nice tooling and easy notation of java and flexibility of XML. Hope it helps Roman
Re: git mirror
+1 On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Hi all, At the risk of opening up a can of worms, would it be possible and/or is anyone interested in having a git mirror of camel's svn repo at http://jukka.zitting.name/git/ ? - aaron -- Cheers, Jon http://janstey.blogspot.com/
[jira] Created: (CAMEL-1297) Seda component should configure its executor
Seda component should configure its executor Key: CAMEL-1297 URL: https://issues.apache.org/activemq/browse/CAMEL-1297 Project: Apache Camel Issue Type: Improvement Components: camel-core Affects Versions: 1.5.0 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Fix For: 2.0.0 Currently SEDA endpoint processes only using 1 thread so it is impossible to easily configure few concurrent processings on 1 seda endpoint. I believe SEDA endpoint could be configured with some executor and/or thread number that we would like to use to process given flows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: git mirror
Hi +1 Can git do patch and apply patches properly? Kinda tired of SVN not having a good patch build in. patch -p0 does not handle file rename, delete etc. to well A patch hell when you get bigger patches to get it merged into the codebase Yeah the feature to stove away current code is great. IDEA has such a feature for SVN = shelve changes. On Tue, Jan 27, 2009 at 1:32 PM, Jon Anstey jans...@gmail.com wrote: +1 On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Hi all, At the risk of opening up a can of worms, would it be possible and/or is anyone interested in having a git mirror of camel's svn repo at http://jukka.zitting.name/git/ ? - aaron -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
RE: Components setting data on OUT
Having finally caught up with the discussion about header/property
copying and propagation, I thought it might be interesting to circle
back to the original question Claus posed (slightly reworded) - what is
the purpose of the out message?
As a flame generator question -
If the exchange only carried 1 message, where each component in turn got
to use and optionally modify.
- how would this be different than the current pipeline behavior ?
Currently if a component sets an out message, it is effectively
replacing the in message for the next one.
- would it not simplify the whole issue of header copying/propagation?
No copying is necessary since it is the same message that travels
through the route
As an optional augmentation of this model, an exchange could carry 2
messages
- the current or working message, which will eventually be the
output of the exchange
- a readonly primordial input message, as provided by the user.
(start the flame...)
-Original Message-
From: Claus Ibsen [mailto:claus.ib...@gmail.com]
Sent: Tuesday, January 27, 2009 1:23 AM
To: dev@camel.apache.org
Subject: Re: Components setting data on OUT
On Tue, Jan 27, 2009 at 6:02 AM, William Tam email.w...@gmail.com
wrote:
On Mon, Jan 26, 2009 at 11:34 PM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:
I think having dots ('.') in property names is not a good idea as
they
don't
get along iirc with some technologies.
Sorry one more thing, the property name is just key to exchange
property map. I believe we already use dots in exchange property
names in some places today.
We have, in the Camel 2.0 design
(http://camel.apache.org/camel-20-design.html) a bullet, that we
should resolve the header key name issue.
James suggested to use a new naming convention CamelComponentName that
I
like.
We should really remove all dots and usage with long packagenames etc.
as the name names dont apply with JMS spec and some other transports.
And I think its something we should do prior to 2.0 release as its a
change that affects many components and internal parts in Camel.
I am glad that I kinda started this ball, this thread sure has proven
that we needed a little heads up and consensus on the
header/properties issue in Camel. Keep the ball rolling.
This is early morning and I am not juiced up for long and deep
thoughts :)
Secondly, my point was that at this time, I am against the idea of
separating the headers into two maps. I don't see a compelling
reason
to do
so and we should properly use properties as Roman and I think Claus
suggested. I'm confident that we'll find a good way to do it.
Hadrian
On Jan 26, 2009, at 11:09 PM, William Tam wrote:
On Mon, Jan 26, 2009 at 5:34 PM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:
On Jan 26, 2009, at 4:17 PM, William Tam wrote:
On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:
I don't disagree, I was just suggesting that they should then
travel as
properties.
Why shouldn't they (protocol headers) travel as headers (to
avoids
unnecessary copying between exchange properties and protocol
headers)?
There should be no unnecessary copying, I agree. If a header
(such
as
username/password) has broadly known and accepted semantics, the
endpoint
or
associated policy could set it as a property from start.
Similarly,
an
endpoint should look at both properties and headers when sending
a
message.
I think I finally get it. Your example of username/password are
really properties in my view. E.g, we can have a property
org.apache.camel.headers.username. It is broadly known in Camel.
Sure, we can stick it in exchange properties and let endpoint read
it
and create a protocol header with it (like, USER=foo). I am fine
with
that idea. That does not make
org.apache.camel.headers.username=foo a
protocol header, though. It really isn't.
I am concerned about true custom protocol header that is totally
unknown to Camel (say, foo=bar). I want my app to be able to
define
and insert some header in protocol message header. I argue that
foo=bar should be set in the header not in exchange properties.
Whatever we name them, and whatever mechanism we decide to use,
as pointed out before, we need to distinguish between headers
that
are
endpoint/protocol specific and have no semantics outside the
endpoint
and
headers (which we called properties and didn't use
consistently)
that
must
be carried over the lifetime of the Exchange.
Custom protocol header fits into no semantics outside the
endpoint
(or else it won't get propagated) and so it goes to the exchange
properties. How does the next component (in the pipeline) know
what
one of the properties are intended to be sent in protocol
header?
Wouldn't it be better to let protocol headers travel as headers
so
only the header candidates will be potentially be sent?
Not sure
Re: git mirror
After a little experimentation the git tooling for IDEA seems pretty good (with a recent git install) 2009/1/27 Ramon Buckland ramon.buckl...@gmail.com: (slightly off topic to camel of course .. I should read the git threads to catch up) .. How is the tooling going in git. To me that is the biggest hurdle for progressing towards any useful ness. I know there is an Eclipse plugin. not tried. don't use git. having said that I am command line junkie .. so show me git! :-) On Tue, Jan 27, 2009 at 23:36, Claus Ibsen claus.ib...@gmail.com wrote: Hi +1 Can git do patch and apply patches properly? Kinda tired of SVN not having a good patch build in. patch -p0 does not handle file rename, delete etc. to well A patch hell when you get bigger patches to get it merged into the codebase Yeah the feature to stove away current code is great. IDEA has such a feature for SVN = shelve changes. On Tue, Jan 27, 2009 at 1:32 PM, Jon Anstey jans...@gmail.com wrote: +1 On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Hi all, At the risk of opening up a can of worms, would it be possible and/or is anyone interested in having a git mirror of camel's svn repo at http://jukka.zitting.namcritical mass.e/git/http://jukka.zitting.name/git/? - aaron -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
[jira] Created: (CAMEL-1298) Resolve the mvn -Psetup.eclipse profile
Resolve the mvn -Psetup.eclipse profile
---
Key: CAMEL-1298
URL: https://issues.apache.org/activemq/browse/CAMEL-1298
Project: Apache Camel
Issue Type: Task
Components: tooling
Affects Versions: Future
Environment: Eclipse
Maven
Reporter: Ramon Buckland
Priority: Minor
Fix For: Future
mvn -Psetup.eclipse is not working as expected.
The idea is that it builds a nice workspace with correct formatting rules as
per project standard and performs a logical eclipse:eclipse on all projects.
it behaves differently to eclipse:eclipse however, dieing when it encounters
(something about) new projects (such as a new component, perhaps not built yet
? is jat not in the repo ? )
{quote}
I have been playing with 'mvn -Psetup.eclipse
-Declipse.workspace.dir=/path/to/your/workspace' and came across some more
issues.
It seems that it configures the workspace okay, and then moves onto
eclipse:eclipse for each project. (or building something in each project).
That 'something fails', on various projects with classes not defined.
I suspect it might be because the actual jar is not in my local repo (not
confirmed though) .. I gather this, perhaps, because the projects that it fails
to compile are ones which are new (freemarker, my new commons-vfs)
hrmm .. not sure what it is.
My eclipse workspace now has activemq code standards.
(a note on that mvn -Psetup.eclipse) So I had a have a new component
(commons-vfs). When I ran -Psetup.eclipse the first time. It failed stating
that all my super classes were not available. (they are in camel-core) .. I mvn
clean'd and reran. it still failed, so I commented it out of components/pom.xml
3rd run - components/camel-freemarker failed with the same sort of error.
Symbol not found (for superclasses it uses).
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1259) POJO messaging example with @Produce @Consume @RecipientList using ActiveMQ
[ https://issues.apache.org/activemq/browse/CAMEL-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=48975#action_48975 ] Jonathan Anstey commented on CAMEL-1259: Put up what I have so far in rev 738191. TODOs - Wiki docs - Use Produce annotation instead of EndpointInject? - Readme.txt - Ant build.xml POJO messaging example with @Produce @Consume @RecipientList using ActiveMQ --- Key: CAMEL-1259 URL: https://issues.apache.org/activemq/browse/CAMEL-1259 Project: Apache Camel Issue Type: Improvement Reporter: James Strachan Assignee: Jonathan Anstey Fix For: 2.0.0 We could really use an example where we just use the annotations to produce, consume and create a RecipientList - all using ActiveMQ (and maybe some other endpoints) http://activemq.apache.org/camel/pojo-consuming.html http://activemq.apache.org/camel/pojo-producing.html http://activemq.apache.org/camel/recipientlist-annotation.html along with maybe a nice test case in the example showing the injection of MockEndpoints and so forth -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: git mirror
Any kind if mirroring or svn browser tends to place big load on apache's servers. On 27/01/2009, Hadrian Zbarcea hzbar...@gmail.com wrote: Aaron, why would infra's involvement be needed? Hadrian On Jan 27, 2009, at 10:58 AM, Aaron Crickenberger wrote: ::sigh:: Actually, since I'm not a committer, I was wondering if one of you fine folks could send a request to infrastructure-...@apache.org? :) - aaron On Tue, Jan 27, 2009 at 9:31 AM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Great to see such support! I've fired off a request to the infrastructure-dev mailing list. As far as the tooling goes I'm still very fresh with git, but so far the command-line and gitk have served me well. GitHub has lots of resources at http://github.com/guides/home if you're curious. - aaron On Tue, Jan 27, 2009 at 7:47 AM, James Strachan james.strac...@gmail.com wrote: After a little experimentation the git tooling for IDEA seems pretty good (with a recent git install) 2009/1/27 Ramon Buckland ramon.buckl...@gmail.com: (slightly off topic to camel of course .. I should read the git threads to catch up) .. How is the tooling going in git. To me that is the biggest hurdle for progressing towards any useful ness. I know there is an Eclipse plugin. not tried. don't use git. having said that I am command line junkie .. so show me git! :-) On Tue, Jan 27, 2009 at 23:36, Claus Ibsen claus.ib...@gmail.com wrote: Hi +1 Can git do patch and apply patches properly? Kinda tired of SVN not having a good patch build in. patch -p0 does not handle file rename, delete etc. to well A patch hell when you get bigger patches to get it merged into the codebase Yeah the feature to stove away current code is great. IDEA has such a feature for SVN = shelve changes. On Tue, Jan 27, 2009 at 1:32 PM, Jon Anstey jans...@gmail.com wrote: +1 On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger aaron.crickenber...@intalgent.com wrote: Hi all, At the risk of opening up a can of worms, would it be possible and/or is anyone interested in having a git mirror of camel's svn repo at http://jukka.zitting.namcritical mass.e/git/ http://jukka.zitting.name/git/? - aaron -- Cheers, Jon http://janstey.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
[jira] Resolved: (CAMEL-1254) camel-cxf: URI option for serviceClass does not support lookup in registry
[
https://issues.apache.org/activemq/browse/CAMEL-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam resolved CAMEL-1254.
Resolution: Fixed
Fix Version/s: 2.0.0
camel-cxf: URI option for serviceClass does not support lookup in registry
--
Key: CAMEL-1254
URL: https://issues.apache.org/activemq/browse/CAMEL-1254
Project: Apache Camel
Issue Type: Improvement
Components: camel-cxf
Affects Versions: 1.5.0
Reporter: Claus Ibsen
Assignee: William Tam
Priority: Minor
Fix For: 2.0.0
Having an endpoint such as:
{code}
String cxfEndpoint =
cxf://http://localhost:8080/part-five/webservices/incident;
+
?serviceClass=org.apache.camel.example.reportincident.ReportIncidentEndpoint
+ wsdlURL=report_incident.wsdl;
{code}
The serviceClass option currently only supports defining a FQN for the class.
I think we need to support Registry lookup as well using the # notation. So
you can do:
{code}
String cxfEndpoint =
cxf://http://localhost:8080/part-five/webservices/incident;
+ ?serviceClass=#reportService
+ wsdlURL=report_incident.wsdl;
{code}
And then have it defined in Spring XML:
{code}
bean id=reportService class=...
{code}
The # notation is already supported if you use the cxf Spring XML
configuration. We need this in the Java DSL as well.
Sorry if it already exists. But I got a hint from a Camel end user that it
didn't
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-1239) Add a busId option for setting the bus for no-spring endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1239 started by William Tam. Add a busId option for setting the bus for no-spring endpoint - Key: CAMEL-1239 URL: https://issues.apache.org/activemq/browse/CAMEL-1239 Project: Apache Camel Issue Type: Sub-task Reporter: Willem Jiang Assignee: William Tam Fix For: 2.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1239) Add a busId option for setting the bus for no-spring endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-1239. Resolution: Fixed Fix Version/s: 2.0.0 Add a busId option for setting the bus for no-spring endpoint - Key: CAMEL-1239 URL: https://issues.apache.org/activemq/browse/CAMEL-1239 Project: Apache Camel Issue Type: Sub-task Reporter: Willem Jiang Assignee: William Tam Fix For: 2.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1256) Clean up camel-cxf
[ https://issues.apache.org/activemq/browse/CAMEL-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-1256. Resolution: Fixed Clean up camel-cxf -- Key: CAMEL-1256 URL: https://issues.apache.org/activemq/browse/CAMEL-1256 Project: Apache Camel Issue Type: Improvement Components: camel-cxf Affects Versions: 1.5.0 Reporter: William Tam Assignee: William Tam Fix For: 2.0.0 The camel-cxf component is dued for some code cleanup and refactoring. We can clean some of of the interfaces and redundant code, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-1289) HeaderFilterStrategy - move from Component to Endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1289 started by William Tam. HeaderFilterStrategy - move from Component to Endpoint -- Key: CAMEL-1289 URL: https://issues.apache.org/activemq/browse/CAMEL-1289 Project: Apache Camel Issue Type: Task Reporter: Claus Ibsen Assignee: William Tam Priority: Minor I am working on CAMEL-505 to allow 100% spring bean configuration of endpoints. When we do this we bypass the xxxComponent that can only be used with the URI configuration. Some components have the headerfilterstrategy that they pass down to the xxxEndpoint. We might wanna consider having getter/setter for headerfilterstrategy on the endpoint itself for spring bean configuration and to default set it to some value to ease the spring bean configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1299) Property language just as the Header language
Property language just as the Header language - Key: CAMEL-1299 URL: https://issues.apache.org/activemq/browse/CAMEL-1299 Project: Apache Camel Issue Type: Sub-task Reporter: Claus Ibsen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
