You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Ranx <ra...@enjekt.org> on 2018/10/17 19:42:23 UTC
Blueprint, DS and CDI State of the Art...
I've been using Blueprint for a few years now and a couple of years ago I was
kicking the tires on DS and CDI. At the time there was a vigorous debate
about the future of OSGi and the place for Blueprint, DS and CDI. I've been
developing in Fuse primarily so was stuck with Karaf 2.x and the standard
libraries. However, I'm going to be doing a Fuse 7 prototype and generating
recommendations for a new clean room implementation and some porting of
older bundles as well.
From what I could tell the use of CDI with DS under the covers was
attempting to solve three problems - (1) it would use the better service
mechanics of DS, (2) provide the dependency injection wire up that DS lacks,
and (3) use a standard paradigm that J2EE developers would find comfortable.
PAX CDI was kicking off at the time and a 1.0 final was released in February
of this year (2018). But I don't see a lot of activity.
https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-197?filter=allopenissues
It's well and fine that all those technologies can pay together in the same
sandbox but I go into clients all the time and a lot of what I do is mentor
them on how to use the stack and especially how to test their code during
development. Teaching different modalities isn't realistic.
Normally that would militate toward adopting Blueprint and the Karaf/PAX
team have done good work at keeping it moving forward. But it doesn't appear
to be tied into much of what is happening with the OSGi alliance and their
directions.
Are the trade offs today the same as when that discussion happened here in
2016 or have things shifted since then.
Any insights would be helpful.
Thanks,
Ranx
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
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: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
Thanks. I'll give it a look.
Unfortunately, as a consultant I'm not at liberty to choose the
implementation I use. My clients are, by and large, using Red Hat Fuse.
Currently Fuse 7 is preloaded with PAX CDI but it sounds as if that may not
remain the same. There have been a number to technology swaps in Fuse which
I didn't agree with but that's out of my control.
Obviously there has to be some mechanic for the OSGi service dynamics or it
would be unusable.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Guillaume Nodet <gn...@apache.org>.
If you really want to pick a CDI implementation to use in Karaf, I would
advise to look at the CDI RI from Aries.
It appears that the spec has evolved in the right direction, also it's
still very limited in terms of beans lifecycle.
The main problem imho is that the spec does not allow tying the lifecyle of
a CDI bean to the lifecycle of its dependencies. That's imho, the best way
to deal with the dynamism of the OSGi service registry.
Guillaume
Le mar. 20 nov. 2018 à 20:42, David Jencks <da...@gmail.com> a
écrit :
> As I noted previously the OSGI CDI reference implementation is at Apache
> Aries and I believe differs significantly from Guillaume’s implementation
> in philosophy.
>
> David Jencks
>
> Sent from my iPhone
>
> > On Nov 20, 2018, at 10:14 AM, Ranx <ra...@enjekt.org> wrote:
> >
> > It appears that Fuse 7 is supporting PAX CDI and that changes my
> assessment
> > of all this.
> >
> > The OSGi Alliance has been positively glacial in approving the
> specification
> > (six years now) but that appears to be about to change. Hopefully they
> adopt
> > Guillaume's implementation as the reference standard and when the final
> spec
> > drops a few tweaks are made to PAX CDI for final.
> >
> > I'm not sure why it has taken so long and having CDI with DS for service
> > annotation while also being able to use the standard annotations for
> > internal bundle wiring is long past due.
> >
> > That Red Hat is supporting CDI means I don't have to worry about
> > recommending it to my clients. That it appears that the OSGi Alliance is
> > about to sign off on the standard is even more exciting.
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
------------------------
Guillaume Nodet
Re: Blueprint, DS and CDI State of the Art...
Posted by David Jencks <da...@gmail.com>.
As I noted previously the OSGI CDI reference implementation is at Apache Aries and I believe differs significantly from Guillaume’s implementation in philosophy.
David Jencks
Sent from my iPhone
> On Nov 20, 2018, at 10:14 AM, Ranx <ra...@enjekt.org> wrote:
>
> It appears that Fuse 7 is supporting PAX CDI and that changes my assessment
> of all this.
>
> The OSGi Alliance has been positively glacial in approving the specification
> (six years now) but that appears to be about to change. Hopefully they adopt
> Guillaume's implementation as the reference standard and when the final spec
> drops a few tweaks are made to PAX CDI for final.
>
> I'm not sure why it has taken so long and having CDI with DS for service
> annotation while also being able to use the standard annotations for
> internal bundle wiring is long past due.
>
> That Red Hat is supporting CDI means I don't have to worry about
> recommending it to my clients. That it appears that the OSGi Alliance is
> about to sign off on the standard is even more exciting.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
It appears that Fuse 7 is supporting PAX CDI and that changes my assessment
of all this.
The OSGi Alliance has been positively glacial in approving the specification
(six years now) but that appears to be about to change. Hopefully they adopt
Guillaume's implementation as the reference standard and when the final spec
drops a few tweaks are made to PAX CDI for final.
I'm not sure why it has taken so long and having CDI with DS for service
annotation while also being able to use the standard annotations for
internal bundle wiring is long past due.
That Red Hat is supporting CDI means I don't have to worry about
recommending it to my clients. That it appears that the OSGi Alliance is
about to sign off on the standard is even more exciting.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
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...
Posted by Francois Papon <fr...@openobject.fr>.
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
fpapon@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...
Posted by Ranx <ra...@enjekt.org>.
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...
Posted by Francois Papon <fr...@openobject.fr>.
Hi,
I'm agree with JB, this the big force of Karaf is to provide all the
possibilities for the users to test and make the right choice for their
own usages.
Karaf is based on OSGi but it doesn't say that users have to use OSGi :)
Keep tune for Winegrower, it will be very nice!
regards,
François Papon
fpapon@apache.org
Le 17/10/2018 à 23:49, Jean-Baptiste Onofré a écrit :
> Hi Ranx,
>
> Blueprint is still maintained and supported by Karaf. There are pros
> and cons for blueprint.
>
> DS/SCR is a nice alternative.
>
> At the end of the day, behind the hood, it's OSGi services, that you
> can use with "native" OSGi approach.
>
> We don't necessary agree with all OSGi alliance directions. Karaf is
> really focus on dev + devops, and specifications should be a way to
> provide new features in an easy way more than a constraint.
>
> We are working on a prototype right now (named winegrower) to provide
> a new experience for developer.
>
> Regards
> JB
>
> On 17/10/2018 21:42, Ranx wrote:
>> I've been using Blueprint for a few years now and a couple of years
>> ago I was
>> kicking the tires on DS and CDI. At the time there was a vigorous debate
>> about the future of OSGi and the place for Blueprint, DS and CDI.
>> I've been
>> developing in Fuse primarily so was stuck with Karaf 2.x and the
>> standard
>> libraries. However, I'm going to be doing a Fuse 7 prototype and
>> generating
>> recommendations for a new clean room implementation and some porting of
>> older bundles as well.
>>
>> From what I could tell the use of CDI with DS under the covers was
>> attempting to solve three problems - (1) it would use the better service
>> mechanics of DS, (2) provide the dependency injection wire up that DS
>> lacks,
>> and (3) use a standard paradigm that J2EE developers would find
>> comfortable.
>>
>> PAX CDI was kicking off at the time and a 1.0 final was released in
>> February
>> of this year (2018). But I don't see a lot of activity.
>> https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-197?filter=allopenissues
>>
>>
>> It's well and fine that all those technologies can pay together in
>> the same
>> sandbox but I go into clients all the time and a lot of what I do is
>> mentor
>> them on how to use the stack and especially how to test their code
>> during
>> development. Teaching different modalities isn't realistic.
>>
>> Normally that would militate toward adopting Blueprint and the Karaf/PAX
>> team have done good work at keeping it moving forward. But it doesn't
>> appear
>> to be tied into much of what is happening with the OSGi alliance and
>> their
>> directions.
>>
>> Are the trade offs today the same as when that discussion happened
>> here in
>> 2016 or have things shifted since then.
>>
>> Any insights would be helpful.
>>
>> Thanks,
>> Ranx
>>
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>>
Re: Blueprint, DS and CDI State of the Art...
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ranx,
Blueprint is still maintained and supported by Karaf. There are pros and
cons for blueprint.
DS/SCR is a nice alternative.
At the end of the day, behind the hood, it's OSGi services, that you can
use with "native" OSGi approach.
We don't necessary agree with all OSGi alliance directions. Karaf is
really focus on dev + devops, and specifications should be a way to
provide new features in an easy way more than a constraint.
We are working on a prototype right now (named winegrower) to provide a
new experience for developer.
Regards
JB
On 17/10/2018 21:42, Ranx wrote:
> I've been using Blueprint for a few years now and a couple of years ago I was
> kicking the tires on DS and CDI. At the time there was a vigorous debate
> about the future of OSGi and the place for Blueprint, DS and CDI. I've been
> developing in Fuse primarily so was stuck with Karaf 2.x and the standard
> libraries. However, I'm going to be doing a Fuse 7 prototype and generating
> recommendations for a new clean room implementation and some porting of
> older bundles as well.
>
> From what I could tell the use of CDI with DS under the covers was
> attempting to solve three problems - (1) it would use the better service
> mechanics of DS, (2) provide the dependency injection wire up that DS lacks,
> and (3) use a standard paradigm that J2EE developers would find comfortable.
>
> PAX CDI was kicking off at the time and a 1.0 final was released in February
> of this year (2018). But I don't see a lot of activity.
> https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-197?filter=allopenissues
>
> It's well and fine that all those technologies can pay together in the same
> sandbox but I go into clients all the time and a lot of what I do is mentor
> them on how to use the stack and especially how to test their code during
> development. Teaching different modalities isn't realistic.
>
> Normally that would militate toward adopting Blueprint and the Karaf/PAX
> team have done good work at keeping it moving forward. But it doesn't appear
> to be tied into much of what is happening with the OSGi alliance and their
> directions.
>
> Are the trade offs today the same as when that discussion happened here in
> 2016 or have things shifted since then.
>
> Any insights would be helpful.
>
> Thanks,
> Ranx
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
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...
Posted by Ranx <ra...@enjekt.org>.
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...
Posted by David Jencks <da...@gmail.com>.
Hi Ranx,
I haven’t been actively involved in osgi for a couple of years, and things aren’t quite where I thought. The enterprise R7 spec is apparently not yet released, but there’s been at least one public draft including the cdi integration spec:
https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2018-06.pdf <https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2018-06.pdf>
Guillaume’s GitHub is not the same as apache aries. I was referring to the actual aries project at
https://svn.apache.org/repos/asf/aries/trunk/cdi/ <https://svn.apache.org/repos/asf/aries/trunk/cdi/>
which is definitely under active development. Since the version is 0.0.2-SNAPSHOT I think there might have been a 0.0.1 release, but I don’t know. I expect there will be a 1.0 release when the spec is released.
As I recall Guillaume had some concerns about the technical direction the spec integration was heading in, but however valid those may have been I fear his solo project is unlikely to have a long term future with the spec integration in place.
David Jencks
> On Oct 18, 2018, at 11:21 AM, Ranx <ra...@enjekt.org> wrote:
>
> 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...
Posted by Ranx <ra...@enjekt.org>.
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...
Posted by David Jencks <da...@gmail.com>.
Note that there is now an OSGI CDI spec with the reference implementation part of Apache Aries. Whatever the technical tradeoffs between this and the PAX CDI one I suspect the latter is not going to be vigorously maintained.
While blueprint certainly works I think that using it is likely to distract from the benefits of an OSGI service model; IMO there’s a big impedance mismatch between the mental models of blueprint and OSGI services making it hard to smoothly flow into creating well designed services. I have no experience or opinion about the CDI approaches.
David Jencks
> On Oct 17, 2018, at 12:42 PM, Ranx <ra...@enjekt.org> wrote:
>
> I've been using Blueprint for a few years now and a couple of years ago I was
> kicking the tires on DS and CDI. At the time there was a vigorous debate
> about the future of OSGi and the place for Blueprint, DS and CDI. I've been
> developing in Fuse primarily so was stuck with Karaf 2.x and the standard
> libraries. However, I'm going to be doing a Fuse 7 prototype and generating
> recommendations for a new clean room implementation and some porting of
> older bundles as well.
>
> From what I could tell the use of CDI with DS under the covers was
> attempting to solve three problems - (1) it would use the better service
> mechanics of DS, (2) provide the dependency injection wire up that DS lacks,
> and (3) use a standard paradigm that J2EE developers would find comfortable.
>
> PAX CDI was kicking off at the time and a 1.0 final was released in February
> of this year (2018). But I don't see a lot of activity.
> https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-197?filter=allopenissues
>
> It's well and fine that all those technologies can pay together in the same
> sandbox but I go into clients all the time and a lot of what I do is mentor
> them on how to use the stack and especially how to test their code during
> development. Teaching different modalities isn't realistic.
>
> Normally that would militate toward adopting Blueprint and the Karaf/PAX
> team have done good work at keeping it moving forward. But it doesn't appear
> to be tied into much of what is happening with the OSGi alliance and their
> directions.
>
> Are the trade offs today the same as when that discussion happened here in
> 2016 or have things shifted since then.
>
> Any insights would be helpful.
>
> Thanks,
> Ranx
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
I've written a lot of Blueprint and Blueprint Camel DSL and Blueprint
bootstrapping Camel Java DSL. But the CDI with annotations is a great way to
get the benefits of DS with automated internal wiring. The problem with
Camel for injection is that @BeanInject and @PropertyInject are Camel
specific annotations. One either has to be coupled to the Camel framework
with them or revert to more antiquated XML setter/getter mechanics for
injection. That gets to be quite a drag when you have multiple levels of
injection of properties and beans. It's also not uncommon to create OSGi
services that are not Camel based so having an injection/annotation system
like CDI that is not Camel based is important.
Also, there are a lot of J2EE developers out there who understand CDI but
don't know OSGi. Providing an easy bridge over is a good move.
Camel Blueprint Test Support is slow and does not use an OSGi container for
testing. It's OK for testing basic wire up. If one uses the Camel Java DSL
that can mitigate some of the problem by permitting tests of routes via Java
and the Camel Test Support which are faster and easier.
Part of the issue with the Camel implementation in Blueprint is that routes
are always defined in the Camel context. So any moderately complex set of
routes becomes testing nightmare. By moving them to Camel Java DSL and
RouteBuilders it means sub-segments can be easily tested.
But it isn't always about Camel and so a universal injection mechanism based
on an industry standard that works with or without Camel would be great. DS
only goes half way unfortunately.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
I'm not sure I've had any particular problems with Camel Blueprint Test
Support except in the olden days when there were some race conditions. On
the other hand, I do know that I have a bit of "Dr. it hurts when i do
this..." relationship with CBTS where I simply won't create certain designs
because they are hard to difficult to test. In some unit test cases that's a
good thing because it is forcing you into good, testable designs. With CBTS
though it can be the case that I'm doing it because I know CBTS will hiccup.
But I use it all the time.
More specifically I don't use Processor/Exchange so all my handlers can be
individually JUnit tested, I use the Camel Java DSL so I can separately test
routes as plain Camel Test Support and then I use Camel Blueprint Test
Support just for wire up and smoke testing to make sure everything is there.
Mockito works well for mocking the OSGi services my bundle is using.
So, I can't say I have any particular problems with tests.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Blueprint, DS and CDI State of the Art...
Posted by Ryan Moquin <fr...@gmail.com>.
Yeah, unfortunately. I hope it at least continues though, fragile or not.
On Tue, Dec 4, 2018, 12:22 PM Christian Schneider <chris@die-schneider.net
wrote:
> The whole camel blueprint as well as camel OSGi integration in general is
> kind of shoehorned on top of a non OSGi system.
> It works but it is a bit fragile.
>
> Christian
>
> Am Di., 4. Dez. 2018 um 16:03 Uhr schrieb Ryan Moquin <
> fragility2.0@gmail.com>:
>
>> I didn't see this thread until now, but just wanted to add that I use
>> blueprint with Camel all the time very successfully. There were a few
>> hiccups that were resolved around injecting configurations into the tests
>> for a specific PID, but in the testing stuff was put together nicely as
>> well.
>>
>> I'd be curious what specific problems you have with it since I was able
>> to figure it out pretty easily from the Camel documentation.
>>
>> I would however like to see some of these hurdles in general get
>> addressed. I'd like to see open source projects in general modularize
>> themselves. When I need to use one that just half-@ssed some osgi
>> support or no osgi support but split packages in their jars, it's quite
>> frustrating. I love writing code using osgi. The power you have is tough
>> to wield at first, but you can do some awesome stuff when you figure it out
>> (and workaround some of the current hurdles still be hashed out).
>>
>> Ryan
>>
>> Ryan
>>
>> On Wed, Nov 21, 2018, 1:34 PM Raymond Auge <raymond.auge@liferay.com
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 21, 2018 at 11:23 AM Ranx <ra...@enjekt.org> wrote:
>>>
>>>> Raymond,
>>>>
>>>> Thanks for the information. I was probably unaware of the RI because it
>>>> isn't listed on the Aries website
>>>
>>>
>>> Good point! So I did some updates to the main page [1]. I will try to
>>> make further updates to other pages as time permits.
>>>
>>> [1] http://aries.apache.org/
>>>
>>>
>>>> and the only annotations I was aware of
>>>> from there were the Blueprint annotations. Also, PAX CDI has been
>>>> installed
>>>> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was
>>>> only the RC so i refrained from using it for production code. Fuse 7 is
>>>> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a
>>>> default.
>>>>
>>>> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube)
>>>> on
>>>> the work you were doing with CDI and OSGi/J2EE. There seemed to be a
>>>> lot of
>>>> work going on there for interoperability with J2EE and not just as OSGi.
>>>
>>>
>>> So there's nothing really specific to Java EE per say other than to
>>> ensure that OSGi CDI Integration could naturally accommodate other CDI
>>> Portable Extensions in a friendly, portable way. As such, integration of
>>> Java EE specs could be accomplished without any hacks. This model could be
>>> used just as easily to make your own features available to your CDI bundles.
>>>
>>>
>>>> For
>>>> me the J2EE part isn't as relevant but if the OSGi service dynamism and
>>>> injection and wire up work correctly that works for me.
>>>>
>>>
>>> Perfect, so there's nothing for you to worry about because this is the
>>> base model.
>>>
>>>
>>>>
>>>> Now to get Red Hat to embrace it and it'll be golden.
>>>>
>>>
>>> Sure, let's see what we can do! ;)
>>>
>>> - Ray
>>>
>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
Re: Blueprint, DS and CDI State of the Art...
Posted by Christian Schneider <ch...@die-schneider.net>.
The whole camel blueprint as well as camel OSGi integration in general is
kind of shoehorned on top of a non OSGi system.
It works but it is a bit fragile.
Christian
Am Di., 4. Dez. 2018 um 16:03 Uhr schrieb Ryan Moquin <
fragility2.0@gmail.com>:
> I didn't see this thread until now, but just wanted to add that I use
> blueprint with Camel all the time very successfully. There were a few
> hiccups that were resolved around injecting configurations into the tests
> for a specific PID, but in the testing stuff was put together nicely as
> well.
>
> I'd be curious what specific problems you have with it since I was able to
> figure it out pretty easily from the Camel documentation.
>
> I would however like to see some of these hurdles in general get
> addressed. I'd like to see open source projects in general modularize
> themselves. When I need to use one that just half-@ssed some osgi
> support or no osgi support but split packages in their jars, it's quite
> frustrating. I love writing code using osgi. The power you have is tough
> to wield at first, but you can do some awesome stuff when you figure it out
> (and workaround some of the current hurdles still be hashed out).
>
> Ryan
>
> Ryan
>
> On Wed, Nov 21, 2018, 1:34 PM Raymond Auge <raymond.auge@liferay.com
> wrote:
>
>>
>>
>> On Wed, Nov 21, 2018 at 11:23 AM Ranx <ra...@enjekt.org> wrote:
>>
>>> Raymond,
>>>
>>> Thanks for the information. I was probably unaware of the RI because it
>>> isn't listed on the Aries website
>>
>>
>> Good point! So I did some updates to the main page [1]. I will try to
>> make further updates to other pages as time permits.
>>
>> [1] http://aries.apache.org/
>>
>>
>>> and the only annotations I was aware of
>>> from there were the Blueprint annotations. Also, PAX CDI has been
>>> installed
>>> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was
>>> only the RC so i refrained from using it for production code. Fuse 7 is
>>> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a
>>> default.
>>>
>>> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube)
>>> on
>>> the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot
>>> of
>>> work going on there for interoperability with J2EE and not just as OSGi.
>>
>>
>> So there's nothing really specific to Java EE per say other than to
>> ensure that OSGi CDI Integration could naturally accommodate other CDI
>> Portable Extensions in a friendly, portable way. As such, integration of
>> Java EE specs could be accomplished without any hacks. This model could be
>> used just as easily to make your own features available to your CDI bundles.
>>
>>
>>> For
>>> me the J2EE part isn't as relevant but if the OSGi service dynamism and
>>> injection and wire up work correctly that works for me.
>>>
>>
>> Perfect, so there's nothing for you to worry about because this is the
>> base model.
>>
>>
>>>
>>> Now to get Red Hat to embrace it and it'll be golden.
>>>
>>
>> Sure, let's see what we can do! ;)
>>
>> - Ray
>>
>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: Blueprint, DS and CDI State of the Art...
Posted by Ryan Moquin <fr...@gmail.com>.
I didn't see this thread until now, but just wanted to add that I use
blueprint with Camel all the time very successfully. There were a few
hiccups that were resolved around injecting configurations into the tests
for a specific PID, but in the testing stuff was put together nicely as
well.
I'd be curious what specific problems you have with it since I was able to
figure it out pretty easily from the Camel documentation.
I would however like to see some of these hurdles in general get
addressed. I'd like to see open source projects in general modularize
themselves. When I need to use one that just half-@ssed some osgi support
or no osgi support but split packages in their jars, it's quite
frustrating. I love writing code using osgi. The power you have is tough
to wield at first, but you can do some awesome stuff when you figure it out
(and workaround some of the current hurdles still be hashed out).
Ryan
Ryan
On Wed, Nov 21, 2018, 1:34 PM Raymond Auge <raymond.auge@liferay.com wrote:
>
>
> On Wed, Nov 21, 2018 at 11:23 AM Ranx <ra...@enjekt.org> wrote:
>
>> Raymond,
>>
>> Thanks for the information. I was probably unaware of the RI because it
>> isn't listed on the Aries website
>
>
> Good point! So I did some updates to the main page [1]. I will try to make
> further updates to other pages as time permits.
>
> [1] http://aries.apache.org/
>
>
>> and the only annotations I was aware of
>> from there were the Blueprint annotations. Also, PAX CDI has been
>> installed
>> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was
>> only the RC so i refrained from using it for production code. Fuse 7 is
>> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a
>> default.
>>
>> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube) on
>> the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot
>> of
>> work going on there for interoperability with J2EE and not just as OSGi.
>
>
> So there's nothing really specific to Java EE per say other than to ensure
> that OSGi CDI Integration could naturally accommodate other CDI Portable
> Extensions in a friendly, portable way. As such, integration of Java EE
> specs could be accomplished without any hacks. This model could be used
> just as easily to make your own features available to your CDI bundles.
>
>
>> For
>> me the J2EE part isn't as relevant but if the OSGi service dynamism and
>> injection and wire up work correctly that works for me.
>>
>
> Perfect, so there's nothing for you to worry about because this is the
> base model.
>
>
>>
>> Now to get Red Hat to embrace it and it'll be golden.
>>
>
> Sure, let's see what we can do! ;)
>
> - Ray
>
>
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: Blueprint, DS and CDI State of the Art...
Posted by Raymond Auge <ra...@liferay.com>.
On Wed, Nov 21, 2018 at 11:23 AM Ranx <ra...@enjekt.org> wrote:
> Raymond,
>
> Thanks for the information. I was probably unaware of the RI because it
> isn't listed on the Aries website
Good point! So I did some updates to the main page [1]. I will try to make
further updates to other pages as time permits.
[1] http://aries.apache.org/
> and the only annotations I was aware of
> from there were the Blueprint annotations. Also, PAX CDI has been installed
> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was
> only the RC so i refrained from using it for production code. Fuse 7 is
> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a
> default.
>
> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube) on
> the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot of
> work going on there for interoperability with J2EE and not just as OSGi.
So there's nothing really specific to Java EE per say other than to ensure
that OSGi CDI Integration could naturally accommodate other CDI Portable
Extensions in a friendly, portable way. As such, integration of Java EE
specs could be accomplished without any hacks. This model could be used
just as easily to make your own features available to your CDI bundles.
> For
> me the J2EE part isn't as relevant but if the OSGi service dynamism and
> injection and wire up work correctly that works for me.
>
Perfect, so there's nothing for you to worry about because this is the base
model.
>
> Now to get Red Hat to embrace it and it'll be golden.
>
Sure, let's see what we can do! ;)
- Ray
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Blueprint, DS and CDI State of the Art...
Posted by Ranx <ra...@enjekt.org>.
Raymond,
Thanks for the information. I was probably unaware of the RI because it
isn't listed on the Aries website and the only annotations I was aware of
from there were the Blueprint annotations. Also, PAX CDI has been installed
in Fuse for some time now although in the 6.x version (Karaf 2.x) it was
only the RC so i refrained from using it for production code. Fuse 7 is
currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a
default.
I think I saw a presentation you gave at Eclipsecon Europe (on Youtube) on
the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot of
work going on there for interoperability with J2EE and not just as OSGi. For
me the J2EE part isn't as relevant but if the OSGi service dynamism and
injection and wire up work correctly that works for me.
Now to get Red Hat to embrace it and it'll be golden.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html