karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Sun, 13 Sep 2015 16:38:59 GMT
Hi JB,

some comments inline.

Am 13.09.2015 um 17:21 schrieb Jean-Baptiste Onofré:
> Hi Milen,
> First, let's take spring-starter-embed out of the picture (it's the 
> part to embed Karaf and applications in a big jar file ready to execute).
> Let's focus on the pure dev path.
> Let me take two use cases:
> 1. Very Simple
> In this example, you have one interface, one bean (business code), you 
> want to expose the bean as a service.
> You can:
> 1.1. Use native OSGi:
>     - Effort: in addition of the business code, you have to write the 
> Activator, knowing the "OSGi API", dealing with the service 
> registration lifecycle. In addition, you have to prepare a Maven 
> pom.xml with bundle as packaging and dealing with maven-bundle-plugin.
>     - Workload: I evaluate that your business code is only 50% of the 
> workload, as you need to write the Activator and the pom.
I would never recommend to use native OSGi for business code as it is 
too error prone. So lets simply leave out this one.
> 1.2. Use blueprint:
>     - Effort: in addition of the business code, you have to write 
> OSGI-INF/blueprint/your.xml blueprint descriptor. So, instead of the 
> "OSGi API", you have to know the blueprint syntax. The pom.xml is the 
> same as in 1.1.
>     - Workload: I evaluate that your business code is 55-60% of the 
> workload. You need to write the blueprint XML, but if you have 
> multiple beans it's probably easier than an activator (not sure ;)).
Alternative: Use CDI annotations and maven blueprint plugin. This should 
result in similar percentages to SCR. The advantage is that the CDI 
annotations are well known and standardized. OSGi services are covered 
with pax cdi annotations.1.3. Use scr annotations:
>     - Effort: you use scr annotations directly in your bean 
> (@Component, @Activate, etc). The pom.xml is the same as the 
> maven-bundle-plugin generate the components XML for you. It requires 
> that your know the SCR annotations (low level), and add required 
> dependencies in the pom.xml
>     - Workload: your business code is 80% of the workload, 20% is 
> about the annotations and pom.xml
I agree with this. Though percentages will be even better in typical 
multi module projects as you can define the maven bundle plugin once in 
the parent.

> 1.4. Use karaf-boot:
>     - Effort: you have the choice between the karaf-boot annotations 
> (high level) or the scr annotations (low level). In the pom.xml, you 
> just have to add a dependency to karaf-boot-starter (for karaf-boot 
> annotations) or karaf-boot-starter-scr (for scr annotations). The 
> karaf-boot-starter* are BoM describing all that you need, including 
> scr dependencies.
>     - Workload: your business code is 85% of the workload, 15% about 
> the annotations and pom.xml. The gap of 5% compared to 1.3 is due to 
> the usage of karaf-boot-starter* that brings all the dependencies for 
> you (you don't have to figure out all dependencies set, etc in your 
> pom.xml).
As you describe yourself the percentage is not much better than scr or 
blueprint approach with annotations. So I think it is clearly not worth 
introducing a proprietary framework for this little advantage.
> So, on this first use case, scr and karaf-good are probably the 
> easiest way to go.
> 2. JPA (the same can be applied to JTA, REST, SOAP, etc)
> In this example, you want to expose a service dealing with JPA/JTA.
> You have an @Entity POJO, and a DAO using JPA and the entity.
> You can:
> 2.1. Use native OSGi:
>     - Effort: you have to create the Activator. The Activator can 
> create an EntityManager or retrieve one as a service. You have to 
> create the META-INF/persistence.xml. You have to call the 
> maven-budle-plugin in your pom.xml, without forget to define the 
> <META-INF/> element.
>     - Workload: your business code is about 40% of the workload, bunch 
> of code has to be written in the activator. You also have to create 
> the META-INF/persistence.xml.
Again lets jut leave it out.
> 2.2. Use blueprint:
>     - Effort: with latest Aries Blueprint versions, you have to create 
> a blueprint XML with <jpa:enable/> element and defining 
> beans/services. You still have to write the persistence.xml and update 
> the pom.xml
>     - Workload: your business code is about 60% of the workload
Like in CDI annotations with blueprint.  Additional you can easily use 
JPA and transactions with pure JTA and JPA annotations. So it is all 
standardized, well known. The annotations are almost exactly like for 
pax cdi. So as soon as it is matured you can siwtch to it easily.

2.2. Use SCR:
> Unfortunately, we don't have direct support of JPA (or other 
> enterprise stuff) in SCR.
The new Aries JPA supports closure based jpa and jta support which is 
almost as nice as annotation based.
I hope we can persuade the SCR people over time to allow interceptors so 
we can close the gap.
> 2.3. Use karaf-boot:
>     - Effort: your just add @jpa(provider="openjpa",dataSource="my") 
> on the your DAO class. karaf-boot will create the persistence.xml for 
> you (and the blueprint descriptor for now).
>     - Workload: your business code is 95% of the workload, 5% is just 
> to define karaf-boot-starter-jpa dependency in your pom.xml.
I think the @jpa annotation is just syntactic sugar. It only saves the 
persistence.xml which is a well known structure  and allows further 
customizations most people need anyway over time.
I agree that the annotation save a bit xml but as you tpyically can just 
copy it from an example or archetype it is not really relevant.
When the project grows the fixed xml size will be less and less relevant.

> For instance, for rest service, it could be the same: right now you 
> have to write a blueprint xml with <jaxrs:server/> element (using 
> CXF-RS). karaf-boot-starter-rest will do that for you, using the @rest 
> high level annotation that you can define on your rest class (where 
> you already have the @Path, @GET, etc jax-rs annotations).
For rest I can imagine using a special annotation. I propose to ot 
include it in karaf though and instead implement it as a plugin to the 
As the Aries goal is to support enterprise development in OSGi I think 
it is a better place to put these efforts.


View raw message