karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Sun, 13 Sep 2015 15:21:44 GMT
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.
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 ;)).
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
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).

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.
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
2.2. Use SCR:
Unfortunately, we don't have direct support of JPA (or other enterprise 
stuff) in SCR.
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.

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

By the way, for all, on the other hand, in the mean time where I'm 
working on karaf-boot, I'm also enhancing the Karaf developer guide, 
with samples.

@Milen, please, don't hesitate to share your thoughts !

Regards
JB

On 09/12/2015 09:13 PM, Milen Dyankov wrote:
> Can someone please point me to an example use case that is "easy" to do
> with SpringBoot but "hard" with Karaf? Some of you mentioned you know
> people that have concidered Karaf but went with SpringBoot because it's
> easier. Is there anything more concrete than the subjective "easy" vs.
> "hard" judgment?
> 12 wrz 2015 20:52 "Jean-Baptiste Onofré" <jb@nanthrax.net> napisał(a):
>
> Documentation is always good, but more than reading the documentation,
> people may want something ready to go with minimal documentation.
>
> I'm working on huge refactoring of Karaf developer guide, providing
> documentation about scr/ds, cdi, jpa, jta, etc. It's time consuming but a
> must have. So it means users will spend so much time just to
> mimic/duplication what's describe in the documentation, ready a long long
> one.
>
> The goal is to simplify the artifact with minimal documentation.
>
> For me, it's different approach: something easy and quick, on the other
> hand detailed documentation for advanced users.
>
> Regards
> JB
>
>
> On 09/12/2015 07:51 PM, garyhodgson wrote:
>
>> Hi JB,
>>
>> A set of BoMs and archetypes, together with the corresponding
>> documentation, would certainly be a great benefit to the project.
>> Particularly if, in the process, it helps resolve outstanding issues such
>> as missing profile documentation, the karaf:run functionality, the
>> developer documentation, etc.  My fear is that the talk of mimicking
>> spring-boot, with @jpa annotations and such, would turn into a time and
>> resource black hole.
>>
>> To your statement: "I bet your spent lot of time and efforts on choosing
>> the right programming model, setup your modules, etc." - this is correct to
>> some extent, but largely due to incomplete documentation about the plethora
>> of options available.  The Enterprise sections of the user guide is
>> woefully inadequate in this regard.  In these cases a Bom or Archetype
>> would give another useful example, but it wouldn't take the place of some
>> well written, and well-maintained documentation about the various
>> technologies available.  Case in point, it was Christian's blog posts that
>> mainly got me up to speed with JPA etc.
>>
>> Regards,
>> Gary
>>
>> On 12 September 2015 at 18:22, jbonofre [via Karaf] <
>> ml-node+s922171n4042537h93@n3.nabble.com> wrote:
>>
>> Hi Gary,
>>>
>>> Your point about the Jira is fair, but this remark applies to any
>>> project. My point is that unfortunately, all our efforts are nothing if
>>> we don't provide tooling for developer users. It's really frustrating to
>>> get feedback like "Karaf is awesome, but I prefer other (like
>>> spring-boot) just because is simpler to start with".
>>>
>>> My goal is not the Karaf starter/bootstrapper first (by the way, I
>>> already have karaf:run ready on one of my branches), it's first a set of
>>> BoM, samples and documentation to quickly start "key turn" artifacts.
>>> Actually, part of karaf-boot came when I work (and still working ;)) on
>>> the Karaf developer guide.
>>>
>>> I bet your spent lot of time and efforts on choosing the right
>>> programming model, setup your modules, etc. That's my concern: it can be
>>> long and sometime complex.
>>>
>>> Regards
>>> JB
>>>
>>> On 09/12/2015 02:23 PM, garyhodgson wrote:
>>>
>>> Hi,
>>>>
>>>> I thought I would add briefly to the discussion my opinion as a relative
>>>> newcomer to OSGi and Karaf, who is evaluating introducing it as part of
>>>>
>>> our
>>>
>>>> architecture at $WORK.
>>>>
>>>> Whilst I can see the attraction of working on some kind of karaf-boot
>>>> offering, my concern is that it would take resources away from other
>>>>
>>> less
>>>
>>>> exciting, yet more important, tasks such as documentation, ensuring
>>>> stability and bug fixing.
>>>>
>>>> Although it's probably not a popular opinion, I would say that working
>>>> through some of the (currently) 559 unresolved issues in Jira should
>>>>
>>> take
>>>
>>>> priority over any new endeavour.
>>>>
>>>> The flexible nature of OSGi and Karaf means that any karaf-boot solution
>>>> would have to be either (a) very opinionated as to what technologies to
>>>>
>>> use
>>>
>>>> (DS, BP, etc), and therefore have a narrow target audience; or (b)
>>>>
>>> highly
>>>
>>>> configurable and consequently almost as complex as implementing a
>>>>
>>> solution
>>>
>>>> from scratch (I think OSGiliath exhibits this trend to some extent).
>>>>
>>>> To introduce Karaf, et al at $WORK, I have ended up creating a
>>>>
>>> multi-module
>>>
>>>> Maven project with a features module, a custom Karaf module, a business
>>>> module with CDI/JPA etc. All of which can be made running quite easily
>>>>
>>> (and
>>>
>>>> could be further enhanced by creating a "karaf:run" type command,which
>>>> sounds like what "karaf-boot-starter" is expected to do.).  Having a
>>>>
>>> "quick
>>>
>>>> start" archetype which sets this up would of course be useful,
>>>>
>>> particularly
>>>
>>>> for those beginning with Karaf, but any realistic project will soon have
>>>>
>>> to
>>>
>>>> change or replace parts to suit their own requirements.  In my opinion,
>>>> having more documentation would provide more value, quicker.
>>>>
>>>> Best regards,
>>>> Gary
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>
>>> http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042534.html
>>>
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4042537&i=0>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>> ------------------------------
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>>
>>> http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042537.html
>>> To unsubscribe from [DISCUSSION] Karaf Boot, click here
>>> <
>>> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4042437&code=Y29udGFjdEBnYXJ5aG9kZ3Nvbi5jb218NDA0MjQzN3w4NTU3ODE3OA==
>>>>
>>> .
>>> NAML
>>> <
>>> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>>>>
>>>
>>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042538.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message