François,
I've looked at the examples and like them quite a bit. An obvious problem
for samples and documentation across a lot of this whether it is OSGi or
Camel is that most focus on obvious problems of how the mechanics work.
Larger integration and testing patterns tend to get short shrift.
David,
Thanks, I appreciate the insights. I suspect from looking at the two
projects Guillaume was working on he simply moved it to PAX after his
initial cut at it but I may be wrong.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Hi,
I agree for the examples and that's why we started add some examples in
the distribution :
https://github.com/apache/karaf/tree/master/examples
We are trying to add more examples in each new releases and be focused
on the users request in the mailing list.
Karaf and Camel are community
David,
Thanks again. I just looked at the Aries and PAX CDI.
https://github.com/gnodet/aries-cdi
https://github.com/ops4j/org.ops4j.pax.cdi
Obviously Guillaume is involved on both but it doesn't look like anything
was done on the Aries version for the past couple of years. I wonder if he
just
François
I'm looking forward to "winegrower". So tantalizing. I guess if you've got
the Cellar you need some wine to put in it.
You're right, the beauty of Karaf/Felix is that you have all these options.
It's also a downside and it becomes even more of a downside when you start
throwing
David,
Thanks! I was unaware of the Apache Aries CDI as separate from the PAX CDI.
It’s exactly that sort of dead end I’d like to avoid. I noted too that
Liferay is doing a clean room implementation of their own version of OSGi
CDI but it seems to focus on bridging a J2EE and OSGi world which is
JB,
Thanks for the feedback. Blueprint itself was never a big issue for me or my
clients so much as Blueprint/Camel. I’m not sure how big a deal Camel is in
the Karaf world writ large. A lot of my concerns are about TDD and also
making sure that standards and libraries adopted don’t become
Absolutely, do use the Camel Java DSL even when you bootstrap with Blueprint.
Write unit tests using CamelTestSupport and only sparingly use the
CamelBlueprintTestSupport. Avoid Processors/Exchanges and use plain pojo
handlers instead. Camel uses reflection on any bean it finds in the path and
Thank you Tim for the affirmation,
Apache Camel, at least, touts that you can tie in so many technologies for just
about any connection technology, any payload, and transform to another, all by
utilizing the massive collection of work done by others, instead of hand coding
it yourself.
Hi,
afaik you can also use declarative Services as starting point for your
Camel routes/rotue-builders
http://camel.apache.org/camel-and-scr.html
Therefore I'd think blueprint isn't mandatory.
Also it's not mandatory to start with a blueprint dsl, use java instead
just let your route builder be
This is an argument that I hear a lot. I’m not a Camel expert, but it really
sounds as though the DSL needs some work. The whole point of a DSL is that by
being domain specific it is supposed to be natural and easy. Instead it sounds
as though it is forcing people into using Blueprint despite
11 matches
Mail list logo
