Re: CDI?

[ranx]

Weird, I didn't see this last year after you posted it. I don't know why. I 
was up here reading on the latest as I'm going to be doing some prototyping 
with Fuse 7 and wanted to see what latest best practices are and where CDI 
is after the February release date. 

I probably should write a blog/tutorial on this stuff. Using Mockito to 
mock OSGi injection, pojos (not Processors/Exchanges) and using standard 
Camel Java DSLs and CamelTestSupport make testing simple. Part of the 
problem I've found with the Blueprint implementation of Camel is if one 
uses the XML the routes are stuck in the Camel context and can't be broken 
down into sub-routes for easy testing. The CamelRouteBuilder mitigates that 
a lot. So you get an onion peel testing of JUnit for basic handlers, 
Mockito for injecting OSGi mock services, CamelTestSupport for testing the 
wire up of handlers and eips with mock services (you have to use the JNDI 
registry in CamelTestSupport and not the OSGi service registry), and only 
use the CamelBlueprintTestSupport for a general sanity check that 
everything is wired and spelled correctly.

One downside is that I end up using the Camel annotations for injection 
then and not CDI or other standard. A small price I guess...I just keep 
hoping we get the best of all worlds at some point with CDI for easy wire 
up and DS mechanics under the covers.

For CXF services I usually use both SOAP and REST annotations on an 
interface and then use a Camel route with either a recipientList using the 
operation name to specify an immediate endpoint or I use the 
toD(direct"${operationName}") to hit a route (I'm writing that off the top 
of my head so may be misrecalling the variable). However, I've also inject 
OSGi services into the CXF bundle and have every method on the web service 
invoke the same direct: endpoint which has a single bean on it - the 
injected OSGi service. Camel uses reflection to select the correct method 
to invoke. That works as long as the requests are uniquely named. Otherwise 
it's back to using the recipientList or toD variant. That means that Camel 
and CXF live in one bundle and the OSGi service just gets messages. I 
should mention that I usually use canonical domain objects so before the 
OSGi service actually gets invoked I'm transforming using Dozer into a 
canonical domain model. That way I don't get protocol/transport artifacts 
like XMLGregorianCalendar leaking into the rest of the world. 

But I use a variety of messaging and not just web services. That's where 
routing between bundles with Camel can be quite beneficial. I might use 
SEDA (VM) during development or even deployment and use a string 
interpolation injected via @PropertyInject for that endpoint and set it in 
the Blueprint by default but can override it in the pid.cfg file. That way 
if I move a bundle the servicing bundle to another container I can change 
the endpoint to a amq: or whatever else it might be. That's rare. More 
usual reasons for changing it would be if the incoming event or any even is 
transactional and I want to drop it on a persistent queue before returning 
an ACK to the client that things are OK.  

But that use case is what I meant by it being loosely coupled. If I'm using 
SEDA on a route and CXF receives an incoming event, converts the object to 
a domain model sans JAXB/XML elements, and then sends it on an endpoint, I 
don't need to decide what the endpoint is until runtime. Default of SEDA/VM 
for development and then it may or may not be the same when deployed 
depending on where the consuming bundle lives.



On Wednesday, August 16, 2017 at 3:42:13 PM UTC-5, Christian Schneider 
wrote:
>
> On 15.08.2017 16:06, ra...@enjekt.org  wrote:
>
> Christian, 
>
> I've also seen a lot of people using Processors/Exchanges which 
> unnecessarily couples their cod to the Camel framework. Unfortunately the 
> Camel in Action book doesn't get around to advising against that practice 
> until your well over 100 pages into the books. And when it does it is in a 
> bulleted list at the end of a chapter. When I'm at client sites it's one of 
> the first things I teach them when mentoring developers. Use POJOs and unit 
> tests just like any other code. Unfortunately neither the Camel website nor 
> the Camel in Action book stress this and too many code examples use 
> Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't 
> recall the last time I used Camel Processor/Exchange directly. 
>
> I think you are on a very good track with this approach and it would be 
> good to spread the word about it. As you wrote it is not emphasized enough 
> in the camel book. So if you have a blog that would be a great theme.
>
> But services aren't more loosely coupled than messaging. If I have bundle 
> A with all its classes unexported in ".internal" package and bundle B in 
> the same situation but they communicate via Camel routes, that's decoupled 
> at compile time and at runtime. 

Re: CDI?

[Christian Schneider]

 On 15.08.2017 16:06, r...@enjekt.org wrote:

Christian,

I've also seen a lot of people using Processors/Exchanges which
unnecessarily couples their cod to the Camel framework. Unfortunately the
Camel in Action book doesn't get around to advising against that practice
until your well over 100 pages into the books. And when it does it is in a
bulleted list at the end of a chapter. When I'm at client sites it's one of
the first things I teach them when mentoring developers. Use POJOs and unit
tests just like any other code. Unfortunately neither the Camel website nor
the Camel in Action book stress this and too many code examples use
Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't
recall the last time I used Camel Processor/Exchange directly.

I think you are on a very good track with this approach and it would be
good to spread the word about it. As you wrote it is not emphasized enough
in the camel book. So if you have a blog that would be a great theme.

But services aren't more loosely coupled than messaging. If I have bundle A
with all its classes unexported in ".internal" package and bundle B in the
same situation but they communicate via Camel routes, that's decoupled at
compile time and at runtime. Injecting a service interface whether it is
through a proxy or not couples the two bundles at compile time and
temporally couples them at runtime. If one puts the service interface into
a separate bundle one now has a different dependency.

Communicating externally is of course very loosely coupled. On the other
hand remote communication is typically a lot more expensive than local
communication using an OSGi service. Another problem with remote
communication is also that it tends to make your domain model anemic. For
the remote communication you need simple DTO like classes. So the logic is
typically separated from the data. If this really is a problem typically
depends on how complex your domain is.
Your approach sounds a lot like a typical microservice approach.

What I currently look into is combining domain driven design and
microservices. I found that making each service in a bounded context a
microservice is creating a lot of overhead. Instead I think it makes sense
to use OSGi services to talk between bundles of the same bounded context.
The border services that form the outside view of the bounded context are a
good match for the camel endpoints you are using.
Btw. What type of communication do you use? REST or more message based?

One other thing I am looking into is how to separate the user code from the
transport protocol.  For this case jax-rs-whiteboard or Aries RSA with CXF
might be interesting for you if you use REST or SOAP. It allows to offer
and consume services without a direct dependency to camel or CXF.
Unfortunately we do not yet have a good solution for one way messaging
based communication / eventing.

best regards
Christian

-- 
Christian Schneiderhttp://www.liquid-reality.de

Open Source Architecthttp://www.talend.com

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[ranx]

I'm not quite sure I grok this. I've used both Blueprint and DS. I've also 
used CDI but it isn't quite ready for primetime.

But CDI permits exporting services, referencing services, and wiring bundle 
internals with injection annotations. It greatly simplifies testing.

So I'm not quite sure what you mean by "there is no framework that solves 
all  your problems."



On Friday, August 11, 2017 at 2:51:42 AM UTC-5, laeubi wrote:
>
> Well in fact here is no framework that solves all your problems... I'm 
> using OSGi and DS for year now and it works without a problem, even 
> though there where sometimes bugs in the code or flaws in my concepts or 
> architectural decsions I had to solve. But I never exspected that DS, 
> OSGi or anything else "solves" this for me in a magical way. 
>
> If you want to use OSGi DS is IMO the best choice (as mentioned before) 
> because it provides what we have with bundles and import/exports to the 
> service level, but must be used with OSGi in mind. The problem is that 
> ppl exspect the can just throw things togeter and it would then work in 
> some magical way. 
>
>
> You can add Blueprint, CDI, Camel and whatever to the mix try to keep 
> away OSGi but will be hurt by "flaky" things then. Thats not the fault 
> of the framework/lib but a restriction of the programming model. I can't 
> find "use of services ends up being complex" but the other way round: 
> Using services with DS is incredible easy and powerfull. So if you have 
> a problem, provide an example and I'm sure you will get help to solve 
> the problem. 
>
> Also DS can of course be used to wire up "things" inside your bundle, 
> what should keep you away of doing so? 
>
> Am 10.08.2017 22:37, schrieb ra...@enjekt.org : 
> > I did use it not too long ago but had to get back to a paying gig. But 
> > the technology is certainly what we need, I think. 
> > 
> > SCR is fine until you then realize that you have wire things up in 
> > your bundle and don't have too many good choices about the matter. 
> > Blueprint is a little long tooth and clunky to work with. From what 
> > I've heard from Christian and others it sounds as though the proxies 
> > have naughty habits. I can say that with time I've drifted away from 
> > using OSGi services when I have a reasonable choice between using a 
> > service and something like a Camel route. A lot of that has to do with 
> > the path of least resistance. I'm putting in a system right now that 
> > has a data source bootstrapped via PAX JDBC which is then consumed by 
> > a "connector" bundle (essentially a DTO). Initially I'd exported that 
> > connector as a service for other bundles to pick up and make service 
> > calls. But the services seemed to have flaky problems when I 
> > uninstalled/installed. Since I had other issues to solve I just fell 
> > back to using Camel routes for data access from other bundles. 
> > 
> > That doesn't seem to be a unique situation for me with Blueprint. 
> > Maybe it isn't Blueprint. But the use of services ends up being 
> > complex and that's a shame. If there's a technology like CDI that lets 
> > me easily export and reference service that will be spectacular. I was 
> > stunned about how easy is to test with the CDI anotations. 
> > 
> > Of course, for bread and butter I'm still consulting on Fuse and 
> > that's not exactly cutting edge 
> > 
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Christian Schneider]

I agree. Not using services in OSGi is a bad idea. Services allow you to
keep your bundles loosely coupled.
You should also try to only use standard java types in your service
interfaces.

I have seen some cases where people share camel routes between bundles or
use camel classes in service interfaces. In the start this seems fun but as
your system grows you realize that the coupling badly hurts your ability to
evolve parts of your system.

Also when using services try to avoid retrieving a service and blocking
until it is there. Instead let DS or another DI framework inject the
service. Especially using DS this will make your system highly reactive to
changes and even work when things are replaced at runtime like in
development. It also copes well with refreshes like they happen a lot in
apache karaf when you install features.

Christian

2017-08-11 9:51 GMT+02:00 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com>:

> Well in fact here is no framework that solves all your problems... I'm
> using OSGi and DS for year now and it works without a problem, even though
> there where sometimes bugs in the code or flaws in my concepts or
> architectural decsions I had to solve. But I never exspected that DS, OSGi
> or anything else "solves" this for me in a magical way.
>
> If you want to use OSGi DS is IMO the best choice (as mentioned before)
> because it provides what we have with bundles and import/exports to the
> service level, but must be used with OSGi in mind. The problem is that ppl
> exspect the can just throw things togeter and it would then work in some
> magical way.
>
>
> You can add Blueprint, CDI, Camel and whatever to the mix try to keep away
> OSGi but will be hurt by "flaky" things then. Thats not the fault of the
> framework/lib but a restriction of the programming model. I can't find "use
> of services ends up being complex" but the other way round: Using services
> with DS is incredible easy and powerfull. So if you have a problem, provide
> an example and I'm sure you will get help to solve the problem.
>
> Also DS can of course be used to wire up "things" inside your bundle, what
> should keep you away of doing so?
>
> Am 10.08.2017 22:37, schrieb r...@enjekt.org:
>
>> I did use it not too long ago but had to get back to a paying gig. But
>> the technology is certainly what we need, I think.
>>
>> SCR is fine until you then realize that you have wire things up in your
>> bundle and don't have too many good choices about the matter. Blueprint is
>> a little long tooth and clunky to work with. From what I've heard from
>> Christian and others it sounds as though the proxies have naughty habits. I
>> can say that with time I've drifted away from using OSGi services when I
>> have a reasonable choice between using a service and something like a Camel
>> route. A lot of that has to do with the path of least resistance. I'm
>> putting in a system right now that has a data source bootstrapped via PAX
>> JDBC which is then consumed by a "connector" bundle (essentially a DTO).
>> Initially I'd exported that connector as a service for other bundles to
>> pick up and make service calls. But the services seemed to have flaky
>> problems when I uninstalled/installed. Since I had other issues to solve I
>> just fell back to using Camel routes for data access from other bundles.
>>
>> That doesn't seem to be a unique situation for me with Blueprint. Maybe
>> it isn't Blueprint. But the use of services ends up being complex and
>> that's a shame. If there's a technology like CDI that lets me easily export
>> and reference service that will be spectacular. I was stunned about how
>> easy is to test with the CDI anotations.
>>
>> Of course, for bread and butter I'm still consulting on Fuse and that's
>> not exactly cutting edge
>>
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> --- You received this message because you are subscribed to the Google
> Groups "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com


-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Christian Schneider]

It is certainly worth to try. I would be very interested in your experience
with the current state of CDI support.

Christian

2017-08-09 17:20 GMT+02:00 :

> Matt,
>
> This is an exchange between Christian and Guillaume from  couple of months
> back when I was asking about this. I've put Guillaume's comments in bold.
>
> DI would be great but it is is less well supported on OSGi than blueprint
> and the current implementations also have the same bad proxy behaviour. So
> while I would like to see a really good CDI implementation on OSGi with
> dynamic behaviour like DS we are not there yet.
>
> *No, the work I've done on CDI is free from those drawbacks. It has the
> same semantics as DS, so anything you can do in DS, you can do in CDI. You
> can even do more than DS because you can wire services "internally", i.e.
> you don't have to expose your services to the OSGi registry to wire them
> together.*
>
>
>
> On Monday, August 7, 2017 at 8:34:57 PM UTC-5, Matt Sicker wrote:
>>
>> I'm not so sure about deprecated, but DS is the only dependency injection
>> standard in OSGi that respects the dynamic nature of services. CDI,
>> blueprint, etc., all have to rely on hacky proxies to emulate support while
>> adding nonstandard extensions at times.
>>
>> On 7 August 2017 at 17:02,  wrote:
>>
>>> I posted this to the Karaf forum but it may more appropriately belong
>>> here. It's going to be one or the other.
>>>
>>> Has CDI been deprecated from the OSGi specification. I was hoping to use
>>> it in the future instead of Blueprint or DS or in addition to them. I re
>>> all last year a new OSGi service export and reference annotations were
>>> added. So this surprised me a bit.
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-11029
>>>
>>> According to that issue, Camel's CDI support for OSGi doesn't work
>>> because CDI on OSGi is deprecated.
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OPS4J" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ops4j+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com


-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[ranx]

What I found odd about the Camel comment that Claus made is that Guillaume 
just put in the CDI annotations for service export and reference last year. 
Initially he did it with Blueprint but swapped it out with DS. I prefer 
working with CDI as there is a lot of testing I can do in Camel that uses 
the CDI wiring mechanisms but I don't have to use CBTS or PAX Exam. The 
internal wiring provided by CDI is a big relief. But the last time I used 
it I couldn't get it working just right. I think that was RC1. The CDI 
annotation mechanism means the paradigm is the same for both internal wire 
up and for external services. Right now working with DS and Blueprint and 
Camel feels like a kludge of items bolted on as an afterthought.

It would be great to have some trustworthy annotations that were usable 
with Camel inside of Karaf/Felix. There are some Camel annotations that I 
trust, some I'm not sure about, and others I know are simply broken. 

One other benefit is that it might make J2EE developers a little more 
inclined to give OSGi/Karaf a shot if that familiar paradigm is available.


On Monday, August 7, 2017 at 8:34:57 PM UTC-5, Matt Sicker wrote:
>
> I'm not so sure about deprecated, but DS is the only dependency injection 
> standard in OSGi that respects the dynamic nature of services. CDI, 
> blueprint, etc., all have to rely on hacky proxies to emulate support while 
> adding nonstandard extensions at times. 
>
> On 7 August 2017 at 17:02,  wrote:
>
>> I posted this to the Karaf forum but it may more appropriately belong 
>> here. It's going to be one or the other.
>>
>> Has CDI been deprecated from the OSGi specification. I was hoping to use 
>> it in the future instead of Blueprint or DS or in addition to them. I re 
>> all last year a new OSGi service export and reference annotations were 
>> added. So this surprised me a bit.
>>
>> https://issues.apache.org/jira/browse/CAMEL-11029
>>
>> According to that issue, Camel's CDI support for OSGi doesn't work 
>> because CDI on OSGi is deprecated.
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Matt Sicker 
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

['Achim Nierbeck' via OPS4J]

Hi,

The OSGi CDI spec was never approved as the champion pushing the spec
withdrew.
At the time People here at OPS4j worked on a CDI implementation which
should follow that spec.
That's Pax CDI, but as the spec was never approved that's basically it.
Though it's functional working.
Besides, the latest CDI 2 specification was supposed to be also used for a
new try to have a OSGi CDI specification.
AFAIK Apache Aries tries to be the home of it.
That's for the CDI stuff, if you are looking for just injection of other
Services, I'd go with DS.

regards, Achim


2017-08-08 3:34 GMT+02:00 Matt Sicker :

> I'm not so sure about deprecated, but DS is the only dependency injection
> standard in OSGi that respects the dynamic nature of services. CDI,
> blueprint, etc., all have to rely on hacky proxies to emulate support while
> adding nonstandard extensions at times.
>
> On 7 August 2017 at 17:02,  wrote:
>
>> I posted this to the Karaf forum but it may more appropriately belong
>> here. It's going to be one or the other.
>>
>> Has CDI been deprecated from the OSGi specification. I was hoping to use
>> it in the future instead of Blueprint or DS or in addition to them. I re
>> all last year a new OSGi service export and reference annotations were
>> added. So this surprised me a bit.
>>
>> https://issues.apache.org/jira/browse/CAMEL-11029
>>
>> According to that issue, Camel's CDI support for OSGi doesn't work
>> because CDI on OSGi is deprecated.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matt Sicker 
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Matt Sicker]

I'm not so sure about deprecated, but DS is the only dependency injection
standard in OSGi that respects the dynamic nature of services. CDI,
blueprint, etc., all have to rely on hacky proxies to emulate support while
adding nonstandard extensions at times.

On 7 August 2017 at 17:02,  wrote:

> I posted this to the Karaf forum but it may more appropriately belong
> here. It's going to be one or the other.
>
> Has CDI been deprecated from the OSGi specification. I was hoping to use
> it in the future instead of Blueprint or DS or in addition to them. I re
> all last year a new OSGi service export and reference annotations were
> added. So this surprised me a bit.
>
> https://issues.apache.org/jira/browse/CAMEL-11029
>
> According to that issue, Camel's CDI support for OSGi doesn't work because
> CDI on OSGi is deprecated.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matt Sicker 

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.