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?

[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?

[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.