Hi
Okay so we have first set of pojo beans in the camel-catalog for almost all
of the out-of-the-box:
- aggregation strategy
- aggregation repository
- idempotent repository
Some of these beans would need a bit more tooling friendly configuration,
and this is something we can work on the next cou
Hi
https://issues.apache.org/jira/browse/CAMEL-17641
For some camel EIPs and components you can use aggregation strategy,
idempotent repository and other kind of beans that Camel provides a API for.
To configure and use these beans then you often would need to find a doc
snippet that has an exam
Date: Wednesday, 26. October 2022 at 16:17
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Hi
Yeah great to hear that it can be donate to Apache Camel.
A PR is very likely the best approach. Then its easier for us to review
gt;
> > From: Andrea Cosentino
> > Date: Wednesday, 26. October 2022 at 14:20
> > To: dev@camel.apache.org
> > Cc: Andrea Cosentino
> > Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the
> > Apache Camel project?
> > I meant to say so
c: Andrea Cosentino
> Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the
> Apache Camel project?
> I meant to say someone from the PLC4x PMC.
>
> But I can have a look too. I'll keep you posted.
>
> Il giorno mer 26 ott 2022 alle ore 14:17 C
Hi Andrea,
I assume you are referring to a normal Git Pull Request procedure, right?
Chris
From: Andrea Cosentino
Date: Wednesday, 26. October 2022 at 14:20
To: dev@camel.apache.org
Cc: Andrea Cosentino
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel
t.
> For the sake of completeness … the code for the component is here:
> https://github.com/apache/plc4x/tree/develop/plc4j/integrations/apache-camel
>
> Chris
>
> From: Andrea Cosentino
> Date: Wednesday, 26. October 2022 at 13:43
> To: dev@camel.apache.org
> Subject: Re: [DI
: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Hello,
Someone from the PMC should try to include the component at least in the
components modules folder..
>From there we could guide him to add the component to the
ris
From: Christofer Dutz
Date: Wednesday, 19. October 2022 at 07:42
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Hi all,
So, the Vote is on its way and looking good so far.
I’ll keep you posted.
Chris
From: Christofer D
Hi all,
So, the vote in the PLC4X Project has passed in favor of moving the PLC4X Camel
component here … so what happens now?
Chris
From: Christofer Dutz
Date: Wednesday, 19. October 2022 at 07:42
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into
Hi all,
So, the Vote is on its way and looking good so far.
I’ll keep you posted.
Chris
From: Christofer Dutz
Date: Thursday, 13. October 2022 at 20:29
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Yeah,
It’s a pretty
that stuff as soon as it’s possible.
But
From: Otavio Rodolfo Piske
Date: Thursday, 13. October 2022 at 08:48
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Hello,
I also think it would make sense to have this component
; >
> > We might help with the migration for sure.
> >
> > Thanks for reaching out to us.
> >
> > Il giorno mer 12 ott 2022 alle ore 16:06 Christofer Dutz <
> > christofer.d...@c-ware.de> ha scritto:
> >
> > > Hi all,
> > >
> >
the migration for sure.
>
> Thanks for reaching out to us.
>
> Il giorno mer 12 ott 2022 alle ore 16:06 Christofer Dutz <
> christofer.d...@c-ware.de> ha scritto:
>
> > Hi all,
> >
> > after a few chats at last week’s ApacheCon, I would like to start a
> &g
ct
> Chris
>
> From: Claus Ibsen
> Date: Wednesday, 12. October 2022 at 12:11
> To: dev@camel.apache.org
> Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the
> Apache Camel project?
> Hi Chris
>
> Thanks for reaching out to us.
>
> I a
Subject: Re: [DISCUSS] Moving the Apache PLC4X Camel components into the Apache
Camel project?
Hi Chris
Thanks for reaching out to us.
I assume its this code that you want to move to Apache Camel
https://github.com/apache/plc4x/tree/develop/plc4j/integrations/apache-camel
That seems very doable as
out to us.
>
> Il giorno mer 12 ott 2022 alle ore 16:06 Christofer Dutz <
> christofer.d...@c-ware.de> ha scritto:
>
> > Hi all,
> >
> > after a few chats at last week’s ApacheCon, I would like to start a
> > discussion on moving the Apache PLC4X Camel compon
’s ApacheCon, I would like to start a
> discussion on moving the Apache PLC4X Camel components into the Apache
> Camel project.
>
> With these components, we are able to read data from industrial
> programmable logic controllers or other hardware and stream that into Camel
> or con
Hi all,
after a few chats at last week’s ApacheCon, I would like to start a discussion
on moving the Apache PLC4X Camel components into the Apache Camel project.
With these components, we are able to read data from industrial programmable
logic controllers or other hardware and stream that
;> the hint that the component is stable enough for this use. That means,
>>>> a
>>>>>>> new component that is being added to camel code base, I'd mark it as
>>>>>>> `Preview`. At least in that sense, it can make sense here.
>>>
d to remember to update all these components manually
over
time.
Regards,
Omar
On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen
wrote:
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are able to define what
maturity/stability
>
> > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga > <mailto:ppal...@redhat.com>> wrote:
> >>
> >> Hi,
> >>
> >> thanks Claus for writing this down.
> >>
> >> On 06/04/2020 09:58, Claus Ibsen wrote:
> >>>
<mailto:ppal...@redhat.com>> wrote:
> >>
> >> Hi,
> >>
> >> thanks Claus for writing this down.
> >>
> >> On 06/04/2020 09:58, Claus Ibsen wrote:
> >>> Hi
> >>>
> >>> Background this PR
> >>> ht
mel code base, I'd mark it as
> > > >>> `Preview`. At least in that sense, it can make sense here.
> > > >>>
> > > >>
> > > >> Yeah but that is also what since version is for, you can see that
> > > >> today, see t
day, see the since column,
> > >> https://camel.apache.org/components/latest/
> > >>
> > >> But yes we could have a default rule in the build tooling so when we
> > >> build a release, it would use preview (if no explicit set and that the
> > >>
t yes we could have a default rule in the build tooling so when we
> >> build a release, it would use preview (if no explicit set and that the
> >> component is new, or N-1 release old).
> >> Then we dont need to remember to update all these components manually
> over
> >>
ont need to remember to update all these components manually over
time.
Regards,
Omar
On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen
wrote:
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are able to define what
maturity/stabili
t;> Background this PR
> >>> https://github.com/apache/camel/pull/3698
> >>>
> >>> a)
> >>> I think it can benefit Camel components if we are able to define what
> >>> maturity/stability level the component is (find a good name). For
&
gt;> Hi,
>>
>> thanks Claus for writing this down.
>>
>> On 06/04/2020 09:58, Claus Ibsen wrote:
>>> Hi
>>>
>>> Background this PR
>>> https://github.com/apache/camel/pull/3698
>>>
>>> a)
>>> I think it
On 06/04/2020 14:26, Claus Ibsen wrote:
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga wrote:
Hi,
thanks Claus for writing this down.
On 06/04/2020 09:58, Claus Ibsen wrote:
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga wrote:
>
> Hi,
>
> thanks Claus for writing this down.
>
> On 06/04/2020 09:58, Claus Ibsen wrote:
> > Hi
> >
> > Background this PR
> > https://github.com/apache/camel/pull/3698
> >
> > a)
> &g
Hi,
thanks Claus for writing this down.
On 06/04/2020 09:58, Claus Ibsen wrote:
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are able to define what
maturity/stability level the component is (find a good name). For
example
N-1 release old).
> Then we dont need to remember to update all these components manually over
> time.
>
>
> > Regards,
> > Omar
> >
> > On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen
> wrote:
> >
> > > Hi
> > >
> > > Background
020 at 9:59 AM Claus Ibsen wrote:
>
> > Hi
> >
> > Background this PR
> > https://github.com/apache/camel/pull/3698
> >
> > a)
> > I think it can benefit Camel components if we are able to define what
> > maturity/stability level the component is (f
6 apr 2020 alle ore 09:59 Claus Ibsen
ha scritto:
> Hi
>
> Background this PR
> https://github.com/apache/camel/pull/3698
>
> a)
> I think it can benefit Camel components if we are able to define what
> maturity/stability level the component is (find a good name). For
> e
eview`. At least in that sense, it can make sense here.
Regards,
Omar
On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen wrote:
> Hi
>
> Background this PR
> https://github.com/apache/camel/pull/3698
>
> a)
> I think it can benefit Camel components if we are able to define what
> matu
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are able to define what
maturity/stability level the component is (find a good name). For
example we could the values that other projects uses such as Quarkus
and WildFly: Stable
jerrinot commented on issue #10: Mark camel components as provided dependencies
URL:
https://github.com/apache/camel-kafka-connector/pull/10#issuecomment-562980307
My pleasure. This project is a great example how various open source
projects can benefit from each other
oscerd commented on issue #10: Mark camel components as provided dependencies
URL:
https://github.com/apache/camel-kafka-connector/pull/10#issuecomment-562978330
Thanks a lot
This is an automated message from the Apache Git
oscerd merged pull request #10: Mark camel components as provided dependencies
URL: https://github.com/apache/camel-kafka-connector/pull/10
This is an automated message from the Apache Git Service.
To respond to the message
Hello all,
I've created a google form to collect statistics about the camel components'
usage
Here is the link
https://goo.gl/forms/ZpBMOXqyC9aeWZRo2
This would be useful for the PMC to understand what component can be
removed/deprecated for the future releases and for Camel 3.
Hi
Ticket: https://issues.apache.org/jira/browse/CAMEL-9419
Just a heads up that the work of this has been merged to master branch.
What it allows is to use spring boot configuration / auto
configuration to configure Camel components. For example IDEA/Eclipse
has tooling that supports this, so
Hi
Just an update that we now have same kind of documentation for the
eips, data formats and languages as well. In other words we have them
all covered.
The camel-catalog contains all the information in a single JAR that
makes it easier for tool providers to have it all from a single
resource; an
On Wed, Jan 7, 2015 at 3:55 AM, Willem Jiang wrote:
> It’s a big movement to make Camel components self documented.
> Thanks for Claus who made this happened.
> I just have a quick question for the camel-extra components.
> Do we have any plan to update these components?
>
Yeah
It’s a big movement to make Camel components self documented.
Thanks for Claus who made this happened.
I just have a quick question for the camel-extra components.
Do we have any plan to update these components?
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http
Hi
Just a note that all components now have been migrated. There is still
a little bit of naming the categorizes etc.
But we got 173 different camel components (schemes) that have been
grouped with labels from a pool of 50 different labels.
On Tue, Dec 30, 2014 at 11:01 AM, Claus Ibsen
Hi
Just an update on the components with latest numbers
Components found: 112
Used labels: 45
Missing components detected: 51
So that mean we have migrated 112 components to be fully
self-documented out of the box. We have categorized these components
using 45 different labels. A component can h
Hi
As part of the upcoming Camel 2.15 we can now associate label(s) to a
Camel component, which allows us to use that to categorize the
components.
We have an outdated and fairly good attempt of grouping the component
in the wiki at: http://camel.apache.org/component-list-grouped.html
Though tha
I am having an Apache Camel Components Poster created through 99designs.com.
This project/contest is currently active as of last night.
Here is the contest:
http://99designs.com/illustrations/contests/create-next-illustration-graphics-gliesian-llc-251085/brief
The poster/contest is being
Thanks a lot Claus!
I will study more the subject, and hopefully will not need to abuse your
availability further ;)
Thanks!
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-features-and-falling-back-to-Camel-components-tp5525681p5535112.html
Sent from the Camel
tions in some way, and
thus they can enlist into a TX manager.
For example a JMS consumer, or a JDBC producer etc.
> Thanks in advance
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-features-and-falling-back-to-Camel-components-tp5
n this subject?
Any help will be very useful!
Thanks in advance
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-features-and-falling-back-to-Camel-components-tp5525681p5534184.html
Sent from the Camel Development mailing list archive at Nabble.com.
y.
See this source for details
https://svn.apache.org/repos/asf/camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/spi/TransactionErrorHandler.java
> Thanks a lot,
> Emanuele
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-features-and-
t to allow camel control it in a transactional way ?
Thanks a lot,
Emanuele
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-features-and-falling-back-to-Camel-components-tp5525681p5533706.html
Sent from the Camel Development mailing list archive at Nabble.com.
Hi,
Not that I can think of. That is indeed the beauty of Camel.
Components and the routing EIPs are separated, so creating components
is simple and plug transparently into the engine that Camel provides.
Having said that, you might want to look leveraging the asynchronous
routing engine in
Hello Bruno,
thanks for replying.
Since I am developing a camel component I though this was the best place to
ask.
It was not clear this is the ML only for "official" camel devs.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-features-and-falling-bac
oyota-europe.com
"E.Gherardini"
29/02/2012 19:09
Please respond to
dev@camel.apache.org
To
dev@camel.apache.org
cc
Subject
Camel features and falling-back to Camel components
Hello everyone,
I am developing a RabbitMQ camel component starting from scratch, using
the
RabbitMQ
eone point me to those, or give me some directions to address my
reasonings ?
Thanks a lot.
Emanuele
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-features-and-falling-back-to-Camel-components-tp5525681p5525681.html
Sent from the Camel Development mailing list
Using commons-io 1.4 across camel components
Key: CAMEL-4684
URL: https://issues.apache.org/jira/browse/CAMEL-4684
Project: Camel
Issue Type: Task
Reporter: Willem Jiang
Thank you, Claus! Great work done.
Best,
Christian
Hi
Ticket
https://issues.apache.org/jira/browse/CAMEL-4031
This is just a heads up that this weekend I migrated 11 components to
not depend on Spring JARs any more.
They were using a tiny piece of the Spring Framework, which is the
Resource loading. For example to load a .xsl file in the classpa
e a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
>
play with Eclipse again to make sure that
plug-in is working right.
I wrapped up the documentation updates today so I think this is done for now.
> Provide a common mechanism to facilitate configuration of TLS across Camel
[
https://issues.apache.org/jira/browse/CAMEL-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated CAMEL-3858:
---
Fix Version/s: 2.7.2
> OSGi bundle data in camel components should import by version num
25th is now in trunk. I polished them
a bit and fixed CS.
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
>
get them into trunk today. If we
wait for long chances are the patching work gets more cumbersome for me.
> Provide a common mechanism to facilitate configuration of TLS across Camel
>
for the optional use of ClassResolver in
order to support Blueprint, the addition of Blueprint support, and support for
Camel Property Placeholders.
> Provide a common mechanism to facilitate configuration of TLS across Camel
> comp
avid.
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/
o use the ClassResolver from the CamelContext in case the TCCL
is not set.
We can provide camelContextId attribute on the JSSE if the user want to use it
across the multiple CamelContext.
Willem
> Provide a common mechanism to facilitate configuration of TLS across Camel
build methods are called rather than
when creating/configuring the builders.
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
>
ate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
>
ate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
>
utility classes to simplify
configuration when using client/server specific overrides on only some of the
shared configuration options.
> Provide a common mechanism to facilitate configuration of TLS across Camel
> comp
ate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
>
, we can think about adding support to camel-blueprint and other camel
components such as camel-mina, camel-netty.
And we can create more sub task to trace these issues.
> Provide a common mechanism to facilitate configuration of TLS across Camel
>
the
camel-blueprint part.
BTW, I will commit the patch shortly after running the tests.
Willem
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
>
oss Camel
> components
> -
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
> Issue Type: New Featu
L and CamelContext specific nature of the current
elements/types in the main schema (Spring and Blueprint).
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> ---
__
Added: svn:mime-type
+ application/octet-stream
{code}
Willem
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
pplication/octet-stream
{code}
Willem
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -
>
> Key: CAMEL-3750
> URL: h
o add
Blueprint support, but I wanted to know if it is possible to close out this
ticket first and then add Blueprint support later?
> Provide a common mechanism to facilitate configuration of TLS across Camel
>
Of course, this is much more interesting to document the endpoint and
not really the component
So @Component will become @Endpoint or JAXB Annotation like suggested by Claus
On Thu, Apr 21, 2011 at 2:38 PM, James Strachan wrote:
> Wouldn't a tool using a combination of introspection & javadoc h
+1
Annotations about the usage of an endpoint would help though, imho.
It would provide the missing info (that needs documenting) like if it's
required, a secret, etc.
While it could be done in javadoc, an annotation could be used in the code to
not printout things like passwords for instance.
Wouldn't a tool using a combination of introspection & javadoc help
make sure the documentation is up to date & valid? It'd work on most
endpoints today without much extra work. Adding extra annotations
could help; but I'd rather have better tools so that code can be more
DRY. e.g. it seems silly a
Yes, karaf uses scaml, scalate to generate the html, pdf documents
On Thu, Apr 21, 2011 at 12:44 PM, Claus Ibsen wrote:
> On Thu, Apr 21, 2011 at 12:40 PM, Charles Moulliard
> wrote:
>> Hey Claus, you know me, I don' t want to reinvent the wheel and prefer
>> to capitalize on existing tools, fra
A bit related there is these JIRA tickets
https://issues.apache.org/jira/browse/CAMEL-2801
https://issues.apache.org/jira/browse/CAMEL-1388
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twit
On Thu, Apr 21, 2011 at 12:40 PM, Charles Moulliard
wrote:
> Hey Claus, you know me, I don' t want to reinvent the wheel and prefer
> to capitalize on existing tools, frameworks.
>
> If I we can use the JAXB annotation, let's go for it, nevertheless,
> I'm a bit skeptical and not sure if it will b
Also its in fact not only Camel components that would be nice to have
documentation in the source code, but auto synced in the apache camel
web pages. It also applies for the EIP patterns as they also have
options. And to some extend Data Formats as well.
We have 2 places where the documentation
Hey Claus, you know me, I don' t want to reinvent the wheel and prefer
to capitalize on existing tools, frameworks.
If I we can use the JAXB annotation, let's go for it, nevertheless,
I'm a bit skeptical and not sure if it will be possible to document
what I want to do.
Remark : We could reuse th
If there is a JAXBDocument annotation in the JDK then we can use that
instead of inventing our own annotation.
And frankly its an universal problem. So there must be better
solutions out there than adding a new annotation to Camel, and
building our own tool to parse the source code and extract the
Hmmm. We do not use JAXB Annotations into component class of camel
**
* FTP Component
*/
public class FtpComponent extends RemoteFileComponent {
public FtpComponent() {
}
public FtpComponent(CamelContext context) {
super(context);
}
So How could it be possible to use w
And we also today have the SNIPPET tag we can use with the confluence
wiki. So you can add those wiki tags in the javadoc and have the code
auto documented.
But thats not the best idea as we would like to migrate the
documentation to scalate like SMX / Karaf and other Apache projects.
On Thu, Ap
Hi
This is the Oracle ticket
http://java.net/jira/browse/JAXB-273
And this was from the original request (they closed this as a
duplicate of that above)
http://java.net/jira/browse/JAXB-369
And this is the Camel ticket
https://issues.apache.org/jira/browse/CAMEL-632
In camel-spring pom.xml th
Can you provide info about what Oracle plan to do that and how we
generate XSD schema from JAXB now ?
Many thanks in advance,
Regards,
Charles
On Thu, Apr 21, 2011 at 9:33 AM, Claus Ibsen wrote:
> JAXB has annotations to generate the XSD schema. There is a RFE at
> Oracle to add an annotation t
JAXB has annotations to generate the XSD schema. There is a RFE at
Oracle to add an annotation to provide documentation. If there was
such an annotation we could use that in the model classes and have
documentation in the XSD as well, which tooling could use (eg in
Eclipse etc.) So I would prefer t
@Component is the annotation used by Spring, this is why I suggested
@CamelComponent ...
Alternative could be @IntegrationComponent
Remark : We could use what has been developed into the
karaf-maven-plugin to generate Docbook.xml doc from annoted classes.
The mojo plugin of karaf is simple as it
@Component is the annotation used by Spring, this is why I suggest
@CamelComponent ...
Alternative could be @IntegrationComponent
On Wed, Apr 20, 2011 at 6:43 PM, Hadrian Zbarcea wrote:
> Since the annotation will be an in a o.a.camel package, I would drop the
> redundant Camel prefix too.
>
>
Since the annotation will be an in a o.a.camel package, I would drop the
redundant Camel prefix too.
Hadrian
On Apr 20, 2011, at 12:38 PM, Charles Moulliard wrote:
> Additional information like isTransactional = True, False, type =
> "ProducerOnly, ConsumerOnly,Both" could be added
>
> @CamelC
Additional information like isTransactional = True, False, type =
"ProducerOnly, ConsumerOnly,Both" could be added
@CamelComponent(name="","description="",example="", pageUrl="",
isTransactional="true/false", type="ProducerOnly, ConsumerOnly,Both")
public class Component {
On Wed, Apr 20, 2011 a
I thought about something similar (and still have a patch somewhere), but I was
focusing on mostly on attributes for the params to describe if they are
required or not, if they are secret or not (i.e. replace them with *** when
printing) and if they are producer/consumer/both side. We can then h
1 - 100 of 196 matches
Mail list logo
