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

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

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

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

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

[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