felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bakker <paul.bak...@luminis.eu>
Subject Re: Building better OSGi applications
Date Sat, 19 Jul 2014 12:17:56 GMT
I assume you're talking about JPA with Apache Aries? I'm not very familiar
with Aries, but if it really requires Blueprint I would seriously consider
not using CMP. It's fairly easy to manage JPA transactions manually, so CMP
doesn't really justify the downsides in my opinion.

Cheers,

Paul


On Fri, Jul 18, 2014 at 8:19 PM, Christian Schneider <
chris@die-schneider.net> wrote:

> I currently see one important case for blueprint.
>
> If you want to use jpa with container managed persistence then blueprint
> is the only working solution in OSGi I know.
> As jpa is used a lot in business applications I think this is an important
> feature. As I generally like DS I would be very interested if there are
> similar solutuions for using jpa with DS.
>
> Christian
>
>
> Am 17.07.2014 12:34, schrieb Neil Bartlett:
>
>  Pretty much, I only take issue with the idea that annotated DS components
>> are not POJOs. The annotations are build-time only so they do not create
>> any runtime dependency. The components can be used anywhere outside of DS
>> and OSGi, including in unit tests. So in what sense are they not POJO?
>>
>> Regarding integration testing, this will be broadly the same with both
>> approaches.
>>
>> I personally prefer DS. One advantage that you didn’t mention is improved
>> laziness since it is purely declarative, whereas DM requires an activator
>> class to be loaded. However I don’t have any real problem with DM… it’s at
>> least a lot better than Blueprint ;-)
>>
>> Neil
>>
>>
>>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message