Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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. 

How do I create a REST service, transform to domain models, route, enrich,
manipulate and then call an OSGi service to handle sending that data to a
database which in turn uses PAX JDBC to bootstrap the JDBC connection and
export it as a Datsource with JNDI filtering? Those are basic integrations
which usually don't have good answers in a holistic sense. The follow up
questions then are how do I develop that in a test driven fashion and what
are the general guidelines to it. 

None of that is rocket science but for a new developer walking into it they
find it frustrating that they have so much power at their fingertips but
can't grok the whole picture. And, of course, such answers commonly span
frameworks. Is that scenario, just described, one for Karaf, Camel, PAX-JDBC
or none of the above. There are good answers to those questions and the
patterns to use and the way to do that in a test driven fashion. 

I believe Christian has written some tutorials along those lines. In any
case, when I set up the prototype and proof of concepts for my client(s),
that's how I like it to be laid out so they are coloring between the lines,
so to speak and can see how it all fits together and how the pieces/bundles
stand alone as well.

I'm also trying to make sure I'm following best practices in terms of using
OSGi while making it easier for newbie OSGi developers to get into. 

It sounds like CDI isn't in prime time shape right now for OSGi. One of the
issues that is probably just an anal personality quirk of my own is that I
don't like using Camels @BeanInject to inject an OSGi service from Blueprint
into my bean/handlers or routes or @PropertyInject to inject substitution
variables for route endpoints. But it does work. If the CDI were farther
along then maybe that would be usable instead.





--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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

Re: Blueprint, DS and CDI State of the Art...

[Francois Papon]

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 projects, everyone can contribute to make
them better in the code, the examples or the documentation.

As you said, it also depend on spare time :)

regards,

François Papon
fpa...@apache.org

Le 18/10/2018 à 22:02, Ranx a écrit :
> 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 technologies like Camel and Camel Blueprint DSL into the mix. 
>
> I think it's OK to support a lot of paradigms but obviously when I'm making
> a recommendation to a client about an architecture, practices, procedures,
> development, testing, and so on, it has to be a standard that the
> organization is going to use. Using multiple paradigms isn't going to go
> over very well as there is already a lot to take in. 
>
> While I think SpringBoot is on the wrong track as an approach, I will say
> that I do think their taking an opinionated approach to development,
> testing,  documentation and code samples is acceptable and preferable. Let's
> hypothesize that the folks in charge of Apache Karaf decided that from now
> on, all code samples would used CDI/DS and its use, testing and practices
> would be rigorously documented. That wouldn't mean that Blueprint was
> abandoned or unusable. 
>
> The cacophony of documentation and code samples is deafening in the
> OSGi/Karaf/Camel world. If Karaf provides a lot of options, Camel does that
> in spades and putting the two together is a square of the problem. I'm not
> sure how may Camel users exist in the Karaf/Felix world but I run into this
> so frequently I've actually thought of setting up tutorials and code samples
> to show simple/easy to follow mechanisms (if only I had a spare minute).
>
>
>
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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 transferred this to PAX and continued the work there?

Anyone know?

Ranx



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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 technologies like Camel and Camel Blueprint DSL into the mix. 

I think it's OK to support a lot of paradigms but obviously when I'm making
a recommendation to a client about an architecture, practices, procedures,
development, testing, and so on, it has to be a standard that the
organization is going to use. Using multiple paradigms isn't going to go
over very well as there is already a lot to take in. 

While I think SpringBoot is on the wrong track as an approach, I will say
that I do think their taking an opinionated approach to development,
testing,  documentation and code samples is acceptable and preferable. Let's
hypothesize that the folks in charge of Apache Karaf decided that from now
on, all code samples would used CDI/DS and its use, testing and practices
would be rigorously documented. That wouldn't mean that Blueprint was
abandoned or unusable. 

The cacophony of documentation and code samples is deafening in the
OSGi/Karaf/Camel world. If Karaf provides a lot of options, Camel does that
in spades and putting the two together is a square of the problem. I'm not
sure how may Camel users exist in the Karaf/Felix world but I run into this
so frequently I've actually thought of setting up tutorials and code samples
to show simple/easy to follow mechanisms (if only I had a spare minute).








--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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 also an
impedance mismatch in models and one I don’t need or want to get into.

I don’t have any great difficulties with OSGi services and Blueprint.
However, the biggest use cases I see personally are Blueprint with Camel and
when folks use the Blueprint Camel DSL now things go sideways. Part of the
issue is with the Camel documentation which stresses using
Processors/Exchanges (obviously not related to OSGi at all but represent
huge challenges for unit testing and are unnecessary) and when you now put
OSGi services into that mix as an orthogonal concern it makes the brain
hurt. If it’s just Blueprint and services, that’s rather straightforward.
Blueprint for configuration management and PID resolution to your .cfg files
is relatively straightforward as well. 

So I always have to have an eye on what is going to work with Camel and the
Camel Java DSL as well as with OSGi services. And for unit testing them. Now
that I’ve figured out a good way to use Mockito for unit testing in Camel
Java DSL with JUnit, CamelTestSupport and CamelBlueprintTestSupport, the use
of OSGi services where they make sense becomes much easier to design. It’s
also easy then to export services from bundles that in turn invoke Camel
routes internal to the bundles.




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Blueprint, DS and CDI State of the Art...

[Ranx]

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 deprecated in
a couple of years and not being an early adopter either. 

I’m at the point with Blueprint that I can use it in a rather minimalist way
and can show developers how to write 90% of their tests and code without
deploying to the container. And I realize this isn’t a Camel forum so that
isn’t party of the Felix/Karaf equation. But the testing with
CamelBlueprintTestSupport was flaky for a long time and uses PojoSR under
the covers while PAX Exam was slow, verbose, and hard to use. So most
developers I ran across just threw in the towel on unit tests and started
doing everything by deployment to container and QA’ing by hand. In doing a
new prototype on a greenfield I’m trying to get ahead of that and need to do
a bit of due diligence on the state of the art. 

I think Blueprint is fine for most of bootstrap, configuration and
export/import of service references. I’m not sure if the XML was ever a good
idea for Camel routes but even if it was going to be used it should have
been written without the routes being defined in the Camel context itself.
That’s a big fly in the ointment for development and testing. Fortunately
just using the Java DSL gets around that and standardizes and let’s
Blueprint work just fine.

The issue with going to DS is that I won’t get the automatic bootstrapping
of the Camel context and the configuration that goes along with it.  I know
how to bootstrap the Camel context from code and worked with an abstract
class that does that. But that isn’t really standard practice. A lot of
clients have problems finding developers who can work with the technology
stack so the closer I can make it hew to a paradigm where Java developers
can simply look at a bundle and get what’s going on and do bug fixes, tests,
and new development, the better. So that’s where CDI has some attractiveness
over Blueprint. 

Ranx




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Running Camel in a Karaf OSGi container

[Ranx]

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
will automatically invoke the correct method on your handler based on
assignment of class type. This means you can use simple JUnit tests on your
handlers. The Camel in Action book recommends that but they don’t get to it
until over 100 pages in and then it’s in the form of a set of bullet points
in the conclusion of the chapter. If you follow those practices it will make
it very easy for Java developers to use OSGi and Blueprint as Blueprint will
only be used for configuration and not for coding.

The issue you’re running into is almost certainly related to not using the
Maven bundle plugin which generates the Manifest automatically. Essentially
the plugin reads your code and your Blueprint file and figures out what
dependencies it needs, what to import and what to export, and writes that
Manifest for you. The OSGi container reads that Manifest to figure out how
to bootstrap everything. The route builder references I show below will then
boot it up correctly.

Using the Java DSL means your code and your knowledgebase is domain neutral.
In other words, your code, tests and skills are as applicable to standalone
applications as to Karaf or Spring Boot or J2EE. Blueprint XML Camel routes
are specific to Blueprint so just avoid them. Eventually you’ll want to look
at features files for installing all your dependencies at start up including
the configuration files. 

If you can get the Camel Blueprint archetype to run, then you should have
everything you need and just use the route builder reference mechanism I
showed below and it will work like a champ. 

This is one of those places where we really do need an “opinionated”
SpringBoot style of coding practices. It’s usually pretty easy to justify
these practices because they result in easily unit tested code that Java
developers understand. Using Camel Blueprint DSL and XML and
Processors/Exchanges always, in my experience, leads to code that has zero
unit tests associated with it.




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Running Camel in a Karaf OSGi container

[John F. Berry]

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. Feeling like I hit a brick wall when it came to "plugging in" one 
Apache product to another, I began to question my technological skills; like I 
must be missing some big concept.  

I don't mean to start a Camel complaint thread, where I whine and carry on.. I 
am still pushing the idea ahead here... that I'm still at a stoppage of further 
progress; that I cannot seem to either start again and redevelop under a 
vanilla Karaf acceptable project.. or port this Java DSL into something that 
can be called from something that runs under Karaf.

If I am to reference a "bean" within a  Blueprint archetype, and my "bean" is 
what is instantiating a Camel context.. Can I simply use a non-camel maven 
blueprint archetype, since the camel-blueprint one is giving me trouble?  I've 
googled all the responses here and attempted what I thought I could do.. but 
one slight off topic thread said it might be my java version?  I did start this 
project with the most current Java to begin, so it would be a bit before it got 
behind, and used Java 10.  Perhaps that is too new to play nice with others?

It's been a bit on this thread since I included my code, so I will send it 
again.
Thanks all!


On ‎Thursday‎, ‎October‎ ‎18‎, ‎2018‎ ‎04‎:‎17‎:‎37‎ ‎AM‎ ‎EDT, Tim Ward 
 wrote: 





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 that being a “less 
preferred” option for some people.

Given the level of Camel integration in Karaf/Blueprint there must be someone 
in the community with the relevant skills to overhaul the DSL and make it fit 
for purpose?

Best Regards,

Tim

> On 17 Oct 2018, at 23:46, John F. Berry  wrote:
> 
> 
> 
> Thank you.. I was thinking of abandoning the Java DSL and ultimately going 
> this way, given my lack of success of "dumping it" into an OSGi container of 
> some sort.  The rest of my shop, though, are not blueprint DSL, Camel or 
> Apache product savvy, so the learning curve for my coworkers will be more 
> disconnected than tapping into their java knowledge.
> I was attempting, originally, to introduce Camel as a solution via Java DSL 
> to encourage its adoption. 
> 
> 
>  
>  
>  On Wednesday, October 17, 2018, 3:50:58 PM EDT, Jean-Baptiste Onofré 
> wrote: 
> 
> 
> 
> 
> 
> You can also directly use the Camel Blueprint DSL directly, just putting 
> your route in OSGI-INF/blueprint/route.xml:
> 
> 
>     http://camel.apache.org/schema/blueprint;>
>         
>             
>             ...
>             
>         
>     
> 
> 
> Regards
> JB
> 
> On 17/10/2018 21:46, Ranx wrote:
>> 
>> You'll want to use the bundle plugin and create a blueprint.xml to bootstrap
>> your Camel Java DSL. I use the Camel Java DSL all the time in Blueprint for
>> a variety of reasons (testing is easier as the RouteBuilders exist without
>> the camel context). I’m not sure why your Camel blueprint archetype is
>> blowing up but I’d start with that first but then you’ll have to modify the
>> blueprint file to add your
>> 
>> Here's a snippet:
>> 
>> 
>> 
>> 
>> 
>>      
>>      > id="document-logic-service"xmlns="http://camel.apache.org/schema/blueprint;>
>>          
>>          
>>      
>> 
>> The RouteBuilders can be independently unit tested then with
>> CamelTestSupport outside the Blueprint container.
>> 
>> This also allows an injection and setup to take place for your route
>> builders when they are instantiated and then when the Camel context is given
>> their reference. Without that step Camel and Felix/Karaf are unaware of
>> their existence.
>> 
>> If you can’t get the archetype to run and create a Camel Blueprint project
>> for you, I’d Google around for a sample project that has the POM correct.
>> 
>> Generally I'll have a features file and configuration file associated with
>> the project as well so that the features repository can be added and
>> installed. There may be a better way to do this with profiles in Karaf 4 but
>> I'm a bit behind the times in that regard.
>> 
>> Ranx
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>> 
> 
> 


http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;>

  4.0.0

  org.somecompany.camel
  EDMtoPSoft-java
  bundle
  1.0.0

  EDM base64 HL7 documents to PeopleSoft

  
UTF-8
UTF-8
  

  

  
  
org.apache.camel
 

Re: Running Camel in a Karaf OSGi container

[Achim Nierbeck]

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 created by blueprint.

As usual, there are many roads to Rome.

Regards, Achim

Am Do., 18. Okt. 2018 um 10:17 Uhr schrieb Tim Ward :

> 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 that being a “less preferred” option for some people.
>
> Given the level of Camel integration in Karaf/Blueprint there must be
> someone in the community with the relevant skills to overhaul the DSL and
> make it fit for purpose?
>
> Best Regards,
>
> Tim
>
> On 17 Oct 2018, at 23:46, John F. Berry  wrote:
>
> Thank you.. I was thinking of abandoning the Java DSL and ultimately going
> this way, given my lack of success of "dumping it" into an OSGi container
> of some sort.  The rest of my shop, though, are not blueprint DSL, Camel or
> Apache product savvy, so the learning curve for my coworkers will be more
> disconnected than tapping into their java knowledge.
> I was attempting, originally, to introduce Camel as a solution via Java
> DSL to encourage its adoption.
>
> On Wednesday, October 17, 2018, 3:50:58 PM EDT, Jean-Baptiste Onofré <
> j...@nanthrax.net> wrote:
>
>
> You can also directly use the Camel Blueprint DSL directly, just putting
> your route in OSGI-INF/blueprint/route.xml:
>
> 
> http://camel.apache.org/schema/blueprint;>
> 
> 
> ...
> 
> 
> 
> 
>
> Regards
> JB
>
> On 17/10/2018 21:46, Ranx wrote:
> >
> > You'll want to use the bundle plugin and create a blueprint.xml to
> bootstrap
> > your Camel Java DSL. I use the Camel Java DSL all the time in Blueprint
> for
> > a variety of reasons (testing is easier as the RouteBuilders exist
> without
> > the camel context). I’m not sure why your Camel blueprint archetype is
> > blowing up but I’d start with that first but then you’ll have to modify
> the
> > blueprint file to add your
> >
> > Here's a snippet:
> >
> >
> > 
> > 
> >
> >
> >   > id="document-logic-service"xmlns="
> http://camel.apache.org/schema/blueprint;>
> >  
> >  
> >  
> >
> > The RouteBuilders can be independently unit tested then with
> > CamelTestSupport outside the Blueprint container.
> >
> > This also allows an injection and setup to take place for your route
> > builders when they are instantiated and then when the Camel context is
> given
> > their reference. Without that step Camel and Felix/Karaf are unaware of
> > their existence.
> >
> > If you can’t get the archetype to run and create a Camel Blueprint
> project
> > for you, I’d Google around for a sample project that has the POM correct.
> >
> > Generally I'll have a features file and configuration file associated
> with
> > the project as well so that the features repository can be added and
> > installed. There may be a better way to do this with profiles in Karaf 4
> but
> > I'm a bit behind the times in that regard.
> >
> > Ranx
> >
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >
>
>
>

-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Running Camel in a Karaf OSGi container

[Tim Ward]

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 that being a “less 
preferred” option for some people.

Given the level of Camel integration in Karaf/Blueprint there must be someone 
in the community with the relevant skills to overhaul the DSL and make it fit 
for purpose?

Best Regards,

Tim

> On 17 Oct 2018, at 23:46, John F. Berry  wrote:
> 
> Thank you.. I was thinking of abandoning the Java DSL and ultimately going 
> this way, given my lack of success of "dumping it" into an OSGi container of 
> some sort.  The rest of my shop, though, are not blueprint DSL, Camel or 
> Apache product savvy, so the learning curve for my coworkers will be more 
> disconnected than tapping into their java knowledge.
> I was attempting, originally, to introduce Camel as a solution via Java DSL 
> to encourage its adoption. 
> 
> On Wednesday, October 17, 2018, 3:50:58 PM EDT, Jean-Baptiste Onofré 
>  wrote:
> 
> 
> You can also directly use the Camel Blueprint DSL directly, just putting 
> your route in OSGI-INF/blueprint/route.xml:
> 
> 
> http://camel.apache.org/schema/blueprint 
> ">
> 
> 
> ...
> 
> 
> 
> 
> 
> Regards
> JB
> 
> On 17/10/2018 21:46, Ranx wrote:
> > 
> > You'll want to use the bundle plugin and create a blueprint.xml to bootstrap
> > your Camel Java DSL. I use the Camel Java DSL all the time in Blueprint for
> > a variety of reasons (testing is easier as the RouteBuilders exist without
> > the camel context). I’m not sure why your Camel blueprint archetype is
> > blowing up but I’d start with that first but then you’ll have to modify the
> > blueprint file to add your
> > 
> > Here's a snippet:
> > 
> > 
> > 
> > 
> > 
> >  
> >   > id="document-logic-service"xmlns="http://camel.apache.org/schema/blueprint 
> > ">
> >  
> >  
> >  
> > 
> > The RouteBuilders can be independently unit tested then with
> > CamelTestSupport outside the Blueprint container.
> > 
> > This also allows an injection and setup to take place for your route
> > builders when they are instantiated and then when the Camel context is given
> > their reference. Without that step Camel and Felix/Karaf are unaware of
> > their existence.
> > 
> > If you can’t get the archetype to run and create a Camel Blueprint project
> > for you, I’d Google around for a sample project that has the POM correct.
> > 
> > Generally I'll have a features file and configuration file associated with
> > the project as well so that the features repository can be added and
> > installed. There may be a better way to do this with profiles in Karaf 4 but
> > I'm a bit behind the times in that regard.
> > 
> > Ranx
> > 
> > 
> > 
> > 
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html 
> > 
> >