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.



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

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