karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From developm...@mobigov.com
Subject Re: [DISCUSSION] Karaf Boot
Date Fri, 11 Sep 2015 15:06:15 GMT

+1 for me as well. I am new to karaf but as I learn more I find I like
to be closer to the ideal. I started with ServiceMix where all was
provided but I just needed rest services with CXF. Not Camel or ActiveMQ
but I had them anyway. I moved down to karaf and eventually moved from
blueprint to DS. Those types of transitions should be as smooth as
possible without causing a lot of rewrite. If profiles and features.xml
are created I should be able to look in my target folder and tell whats
going on. Eventually if I want to take something out and override the
generated features or profile I hope it is easy. 

thanks for all the work you guys do and effort you put into helping
others get started. Even if I do not feel these features are for me I
hope to be able to see what they are doing so I can pick up best

David Daniel 

On 2015-09-11 04:09, Morgan Hautman wrote: 

> That's a +1 for me :)
> On 09/11/2015 09:54 AM, Jean-Baptiste Onofré wrote:
> After discussing with Achim, I'm doing a refactoring: instead of using a parent file,
I will prepare a set of karaf-boot-starter* that we can define as dependency of a project,
and it's done. It's actually a set of BoM expressed as karaf-boot-start* pom, that the developers
can just depends on (and not inherit). Regards JB On 09/11/2015 09:32 AM, Achim Nierbeck wrote:
Hi Christian, comments inline. regards, Achim 2015-09-11 9:26 GMT+02:00 Christian Schneider
<chris@die-schneider.net>: Hi Achim, very good overview of the problems users face and
I also agree with your proposed solutions. Just for pax cdi I think we are not yet there so
I would go with blueprint generation from CDI annotations for now and switch to proper pax
cdi when it is fully working. absolutely, therefore my proposal to improve what we have. On
top I would add that I have the feeling that springsource more or less hyped microservices
because they know spring does not scale! The bigger a spring application grows
the more you see that it does not provide real modularization. 1. All of the dependencies
have to be hammered into a flat classpath. This works or an astonishingly long time but at
some point in the growth of a project it gets harder and harder. 2. The single spring context.
In the end the whole application runs on one merged spring contex. All the settings done in
the small contexts scattered around the project artifacts have to work together in the big
context created at runtime. 3. No enforcement of visibility rules. You can define an API but
you also have access to all the impls and developers tend to use them when the time pressure
comes. 4. Static setup. Spring has to boot up all beans in the correct order. 5. They tried
with OSGi but I think they realized that making spring fully OSGi ready is too much work full
ack, that's my critique of spring since years. All this leads to people thinking that an application
needs to be split into microservices to make the above problems
smaller. Only later they find that implementing microservices is pretty hard. The biggest
problem is that they may not share a database. So you have to invent a lot of additonal logic
to keep the different databases in the same state. Additionally there is security and monitoring
which is also pretty much unsolved in microservices. If you compare this to a proper OSGi
application then the need for the spring style microservices is almost not there. Instead
you write small modules with a clearly defined API and boundaries and OSGi services to communicate.
If you need to cross server boundaries then OSGi remote services allow to extend the OSGi
services model to a larger environment. you'll see that in my talk at apache-con :D So I would
argue that the microservices hype will not live to its promises. People will realize that
OSGi provides better solutions with less overhead than microservices. This will take some
time of course and we will need to make sure to not loose too many
people to spring boot in the mean time. So what we need is a nice way to create microservices
in karaf like you described. Additionally we should also allow people to just deploy a normal
OSGi application in a simple way like you would for a microservice. So I think we need to
make sure that karaf boot not only works for single projects but also for whole applications
in form of a set of bundles. This will allow people to transition away from pure microservices
when they realize they are not as good as they think while still keeping a lot of the benefits
of the small and simple deployment unit. yep, that's my intention and thanks for the feedback.
Christian Am 10.09.2015 um 23:58 schrieb Achim Nierbeck: Hi after reading this thread about
two times, I finally understood the intention and the confusion in the thread. Let me try
to summarize this to start some more confusion :-D Initial Problem: - learning OSGi has a
steep learning curve - initial setup for a new OSGi project needs a
lot of infrastructural "thingis" - doing the "microservice" dance is hard as it requires to
much "extras" to have a simple REST service -- including infrastructure - Spring boot brings
everything needed in one place in one "application" with just annotations These are the "problems"
we know of and if I did get it right are the intention for the Karaf-Boot project. Now let
me try to summarize the idea on how to solve that. From a simple Class file with some annotation
generate - a OSGi service, including OSGi wiring via Blueprint - via an extra maven plugin
- get rid of all those infrastructural "add-ons" for the first OSGi bundle by having a easy
to use Parent-POM - do the microservice - dance by wrapping everything together including
CXF in a "one-size-fits-all" executable jar, which is a wonna-be-spring-boot jar but made
of karaf Now some thoughts of mine ... I somehow fear you try to mix several problems and
try to solve all of them with one go. Let's try to analyze those initial
problems separately and we might find a valid approach. Learning curve of OSGi: right now
we have different approaches to make it easier with OSGi. - Blueprint - DS - CDI - iPojo -
Felix DependencyManager Blueprint just tastes to much like spring xml and actually isn't state
of the art anymore. You'll get a lot of negative feedback regarding the "old-school" xml.
It's biggest plus is the Enterprise "features" like JPA and JTA, which isn't covered by any
other technique right now (unless you look at non Apache Hosted OSS projects like Amdatu).
Declarative Services, especially the latest R6 looks rather promising, especially in conjunction
with MetaType. But we have specialized annotations which again don't actually help with the
learning curve. Another downside is the missing JPA and JTA Enterprise features. CDI, we have
the Pax-CDI project which has been on the way of being the reference implementation of the
OSGi-CDI spec. Well, we all know how that turned out. One of its biggest
benefits is definitely the easy transition because of the CDI annotation which help a lot
with wiring inside a bundle and also with extra annotations (@OsgiService) with OSGi-Services.
CDI though still lacks runtime OSGi annotation support for JPA and JTA if we are somehow capable
to compensate that, we'll have the required EE stack at hand. iPojo ... sorry never used Dependency
Manager is a bit more low-level compared to DS but seems to have a nice DSL for easy wiring
of Services. So do we really need another Build-Time-Annotation which generates another "wiring"
plan which is used during runtime (exactly what DS already does)? Right now I'm not convinced
of this. Instead of another generation I would prefer to use CDI as it is known to work in
classic Spring/EE world and OSGi. Instead we should focus on bringing the full support of
Enterprise style annotations to the OSGi world. Initial Setup for a new OSGi Bundle Project
Instead of a parent POM I think it would be much more
beneficial to work with a BOM (Bill of Material) for easier development, especially when working
with std. CDI annotations plus some extra PAX-CDI ones. Maven Archetype are actually good
enough to create an initial structure for a maven project. The big benefit of the spring-boot
approach is to actually have a bunch of different BOMs that can be used to add certain functionalities
to the project, aka spring-boot-*-starter. To start a karaf-boot I think we should first try
to have a karaf:run available as maven plugin. The microservice dance actually it's just add
a rest-service on top of a OSGi service, that's all that is needed in Karaf. Right now I'm
not in favor of any certain framework. CXF seems a bit bloated but is known to work, but requires
blueprint. Jersey, I've seen that to be working with "plain" OSGi. A bit of polishing and
it should be quite easy to use, especially with CDI at hand. But it needs more to dance the
microservice dance, you need "small" containers ... which
is quite contrary to the way Karaf and OSGi in general is working with services. But this
is the point I think the karaf profiles come in handy. You don't need a full blown Karaf,
just a basic infrastructure with your own Bundle, might as well ignore the shell. In the end
dump that into a docker container and if you need to do a bugfix do it the "docker" - way.
spring-boot brings it all in one go karaf-boot should do the same, but actually I fear we
do more then needed. For a new Project setup I'd rather would like to see different karaf-starter-*
BOMs and a karaf:run maven plugin Some more docuementation for the profiles of Karaf could
also be helpful :D to build minimalistic karaf instances runnable in docker containers. Regarding
the karaf:run it might be interesting to "re-activate" the pax:run maven plugin to run nicely
with a karaf instance, or use it as foundation for the karaf:run maven plugin. So in the end,
do we really need all this? I'm not so sure, but we surely need an
easier "to use" approach. Therefore we should first focus on having easier setup of bundle
development. -> karaf-boot-starter-* BOMs should take care of that -> karaf:run should
make it easier to have a running container Do we need new annotations? I can't see that yet.
Instead we should/could focus on the following: a) make sure DS also is capable to work with
JPA/JTA and some other enterprise annotations b) make sure CDI works with runtime JPA/JTA
annotation smoothly c) provide more demos and archetypes with OSGi and CDI annotations regards,
Achim 2015-09-10 20:41 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>: Thanks Milen,
it's an open place to discussion. We just share standpoints and opinions: that's the key part
!!! My goal is to give more traction on Karaf by providing easier We all provide valid points,
but I think we are not the most setted to argue as we are deeply involved in OSGi and Karaf.
The karaf-boot proto came when discussing with new Karaf users, coming from
"outside" of OSGi, or people that decided to use spring-boot (even if they like a lot Karaf),
just because it's easier. It's hardly frustrating for us as we just need some tooling to provide
even more traction. On the container side, I think Karaf is already great, and answers all
needs. The part where we should improve what we deliver is around developer tooling: easier,
faster, key turn. If karaf-boot will be a success, I don't know (who knows ? ;)). But anyway,
it brings points, questions, and identify some missings in the current picture. My $0.01 ;)
Regards JB On 09/10/2015 08:02 PM, Milen Dyankov wrote: Well I was just referring to your
example but I get your point. Which reminds me of EnRoute <http://enroute.osgi.org/ [1]>
project which despite the big names and the most popular OSGI build tool behind it, doesn't
seem to get as much traction as I expected! That said, I really admire your enthusiasm and
wish KarafBoot can be more successful that that. I'm not trying to
discourage you! Just it seams what you are after is something that other people have tried
already with questionable success. Best, Milen On Thu, Sep 10, 2015 at 7:22 PM, Jean-Baptiste
Onofré <jb@nanthrax.net> wrote: And how to you deal with jpa, jta, rest, etc with SCR
annotations ? Regards JB On 09/10/2015 07:16 PM, Milen Dyankov wrote: So correct me if I'm
wrong but if I get the sample you provided in the first mail and replace: - the parent pom
with "maven-bundle-plugin" - @Bean with @Component - @Init with @Activate wouldn't that have
the exact same end result? I mean it obviously differ in terms of what gets generated (Blueprint
vs DS) but form end user perspective there is no difference, right? On Thu, Sep 10, 2015 at
6:55 PM, Jean-Baptiste Onofré < jb@nanthrax.net> wrote: Hey Milen, Actually, there's
too part: 1/ karaf-boot-starter will do the ready to start artifact, embedding karaf, but
it's another point 2/ the value of karaf-boot annotations and plugin is first to
simplify the bundle/artifact ready to be deploy-able into Karaf (generate the "plumbing" easily
for developers). Regards JB On 09/10/2015 06:50 PM, Milen Dyankov wrote: " ... that you deploy
in Karaf ..." OK may be I misunderstood the concept. I thought the result is standalone executable
JAR, thus my comments above. If on the other hand I need to install Karaf and then deploy
my services into it I really don't see how it differs form what people are doing now? I'm
sorry if I'm not making much sense. I didn't have the time to experiment with your code and
samples so may be I'm missing an important peace here. Best, Milen On Thu, Sep 10, 2015 at
6:27 PM, Jean-Baptiste Onofré < jb@nanthrax.net> wrote: Allow me to disagree: Karaf
is a perfect container for microservices. Image to create a microservice (using karaf-boot)
that you deploy in Karaf and use such service in another microservice, all wired with OSGi
service and Karaf: we leverage OSGi/Karaf as a microservices container. But
even without talking of microservices, new developers to Karaf (and OSGi generally speaking)
are frustrated by the effort on non business code to do (I have to write an Activator, or
a descriptor, etc, etc). So, a tooling to simplify this is still a valid addition IMHO. Regards
JB On 09/10/2015 06:23 PM, Milen Dyankov wrote: I might be wrong but I think the whole success
of SpringBoot (apart from having the "Spring" in it) is the microservices hype! it's quick
and easy but most usecases follow the "create one (or very few) service(s), pack them as single
executable and access them via REST" pattern. We can obviously do the same with OSGi and Karaf
in particular but personally I think this makes absolutely no sense. In such approach one
in not benefiting form OSGi almost at all. Honestly speaking I would argue that if one does
not understand how OSGi service layer works (regardless of the framework used to register/access
services) it makes no sense to use OSGi at all. Just my 2
cents! Regards, Milen On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider < chris@die-schneider.net>
wrote: I already created such a maven plugin in aries. The user can use standard CDI and JEE
annotations and the result is blueprint xml. How is the new approach different / better? Why
should it be good for the developer to move away from well defined standard annotations and
use custom annotations that bind him to karaf? I mean if this is created by the spring guys
I know they want to catch people by perceived simplicity and then make sure to make it difficult
to switch. As an open source comminity I do not know why we should do something like this.
Abstracting away from frameworks just means you create another layer that people then also
have to learn. There were some cases in the past where this make sense because the underlying
frameworks sucked (like JEE 2). This is not the case today though I think. What kind of use
case do you have in mind? Every project starts small but it
needs to be able to grow then. You can not start with custom annoations and then tell people
to later switch to something else when the project grows. I think it makes more sense to make
it easier for people to use the standard annoations and use the right dependencies. If we
simply provide a tooling that makes it easy to start with SCR or blueprint we provide much
more value for people as thery can then grow without any breaking changes. Christian Am 10.09.2015
um 17:46 schrieb Jean-Baptiste Onofré: Because all these annotations are runtime: here we
talk about tooling at build time. More over, the purpose is to provide more high level annotations,
which abstract actual annotations/frameworks that we can use under hood. The purpose of centralizing
all in karaf-boot is to have a central project: the developer just use karaf-boot, it doesn't
really know what technologies are involved behind the scene. For instance, in spring-boot,
they use activemq, jersey, etc, but all from
spring-boot. The developers don't know a rest service use jersey for instance, it's completely
abstracted. Again the purpose is to simplify life for developers: splitting the annotations
in different projects introduces complexity (at least to find the dependencies and core import
packages). If an advanced developer wants to use CDI, SCR, etc, he can of course. Regards
JB On 09/10/2015 05:40 PM, Christian Schneider wrote: I am not really enthusiastic about duplicating
functionality of cxf or aries. Aries supports a very nice approach for injections, jpa and
jta. Why should it make sense to recreate that? Aries blueprint also has annoation support
even in two flavors (CDI, custom). How does the new approach interact with this? Instead I
propose we create support for such annotations in the respective projects (where they are
missing) and concentrate on karaf as a container not an application development framework.
By leveraging the existing frameworks we profit from their own
development teams. Whatever we recreate will have to be developed by the very few resources
of the karaf team. Christian Am 10.09.2015 um 16:53 schrieb Jean-Baptiste Onofré: Hi Guillaume,
thanks for your feedback. I fully agree about providing more high level annotations (it's
what I do with @jpa, @rest, @soap, @jta annotations). I agree that the current annotations
are too low level, and blueprint "oriented". I just move forward a bit with the current codebase,
just to illustrate karaf-boot usage in the samples. But again, you are right, and I will create
a new annotations set. One of the purpose of karaf-boot annotations is to "abstract" the actual
code/artifact that we generate. So, if now we generate blueprint, without changing the karaf-boot
annotations, we will be able to generate something else (why not SCR, etc). I agree with a
BOM, but I think it's interesting to provide both: - providing a ready to use parent pom allows
developers to create a very simple pom.xml where all
plugins and dependencies are already defined - for more advanced devs, they can create their
own pom.xml starting from the BOM or archetype. Thanks again for your feedback ! Regards JB
On 09/10/2015 04:44 PM, Guillaume Nodet wrote: I like the idea. For the annotations, we need
to keep really high level. The annotations in the code base right now are much too close to
blueprint. I think we need to grab a small enough subset so that the annotations are easy
to understand for beginners and without any ambiguities, even at the cost of features. For
example, I think we should restrict to constructor injection, so that we don't have any bind
/ rebind / init methods. We simply need an optional @Destroy. In case the dependencies change
at runtime, simply destroy the bean / service and recreate it the dependencies are still met
after the change. If blueprint is to be hidden completely, we may find a better alternative
in SCR or even Felix Dependency Manager, but it does not matter too much
for now. I agree with the idea of using a BOM instead of a parent if possible. I'm not very
familiar, but this is less invasive. The real problems will come with the support of higher
level annotations for JAXRS, JPA, etc... Not really sure how to handle those yet... 2015-09-09
16:32 GMT+02:00 Jean-Baptiste Onofré < jb@nanthrax.net : Hi all, I worked on a prototype
about Karaf Boot. Let me give you some backgrounds and discuss about that all together. Why
Karaf Boot ? ---------------- When you develop artifacts (bundles) to be deployed in Karaf,
you can see that the actual time that you spend on your business code is finally largely less
important that all the plumbing effort that you have to do (writing OSGi Activator, or blueprint/scr
descriptor, etc). It means that your "go to market" is longer, and we should provide something
that allows you to focus on your code. Even if SCR annotations is a very good step forward,
some use cases are not so easy to do (JPA, JTA for instance).
And anyway, you have to prepare your pom.xml with different plugin and dependency. Moreover,
when you have your artifacts, you have to prepare Karaf container, and deploy those artifacts
there. Even if it's "container" approach is the most important for me, we can give even more
flexibility by providing a way to embed and prepare Karaf in a ready to execute jar/artifact.
What is Karaf Boot ? -------------------- Karaf Boot provides four components: * karaf-boot-parent
is the Maven parent pom that your project just inherit: that's all ! All plugins, dependencies,
etc are described in this parent, you even don't have to define packaging as bundle, standard
jar is fine. * karaf-boot (coming with karaf-boot-parent) provides annotations that you use
directly in your business code (like @Bean, @Service, @Reference, @Inject, etc): again, your
focus on your code, karaf-boot deals with the plumbing. * karaf-boot-maven-plugin (coming
with karaf-boot-parent) scan the classes and generate a
blueprint XML. For now, I'm using blueprint generation (because we can cover lot of use cases,
for instance, I plan to provide @rest annotation that will generate blueprint XML with cxf
jaxrs server, etc). * karaf-boot-starter is the module providing a convenient way to embed,
configure and bootstrap Karaf. Just to illustrate this, let's take a look on the karaf-boot-sample-simple.
The pom.xml is really simple: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0
[2]" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance [3]" xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0
[2] http://maven.apache.org/xsd/maven-4.0.0.xsd [4]"> <modelVersion>4.0.0</modelVersion>
<parent> <groupId>org.apache.karaf.boot</groupId> <artifactId>karaf-boot-parent</artifactId>
<version>1.0.0-SNAPSHOT</version> </parent> <artifactId>karaf-boot-sample-simple</artifactId>
<version>1.0.0-SNAPSHOT</version> </project> You can see, the only thing
that the developer has to
do: define karaf-boot-parent as parent pom. That's all. Now, in the code, you have just one
bean that we want to run: package org.apache.karaf.boot.sample.simple; import org.apache.karaf.boot.Bean;
import org.apache.karaf.boot.Init; @Bean(id = "simple-bean") public class SimpleBean { @Init
public void simple() { System.out.println("Hello world"); } } You can see the @Bean and @Init
karaf-boot annotations. The karaf-boot-maven-plugin will generate the blueprint descriptor
using this. Current Status -------------- I pushed Karaf Boot structure there: https://github.com/jbonofre/karaf-boot
[5] It's a mix of rewrapping of existing code (from aries, pax-exam, etc) and additions. I
created the annotations, I'm now working on the karaf-boot-maven-plugin based on Christian's
work in aries (I'm actually scanning the boot annotations now, and generating the XML). I
will push new changes later today and tomorrow. Open Questions --------------- * For now,
I would prefer to be 'artifacts' and
'resources' generator: I think it's better than to depend to a feature running in Karaf, but
it's open to discussion. * I'm now generating blueprint. Probably native OSGi or scr generation
can make sense. * I'm generating bundles: thanks to the Karaf4 features resolver, as the bundles
provide requirements/capabilities metadata, I think it's a good start. However, maybe it's
worth to be able to create features, kar, profile. Thoughts ? Thanks, Regards JB -- Jean-Baptiste
Onofré jbonofre@apache.org http://blog.nanthrax.net [6] Talend - http://www.talend.com [7]
 Jean-Baptiste Onofré jbonofre@apache.org http://blog.nanthrax.net [6]
Talend - http://www.talend.com [7] -- Jean-Baptiste Onofré
jbonofre@apache.org http://blog.nanthrax.net [6] Talend -
http://www.talend.com [7] -- Jean-Baptiste Onofré jbonofre@apache.org
http://blog.nanthrax.net [6] Talend - http://www.talend.com [7] --
Jean-Baptiste Onofré jbonofre@apache.org http://blog.nanthrax.net [6]
Talend - http://www.talend.com [7] 

[1] http://enroute.osgi.org/
[2] http://maven.apache.org/POM/4.0.0
[3] http://www.w3.org/2001/XMLSchema-instance
[4] http://maven.apache.org/xsd/maven-4.0.0.xsd
[5] https://github.com/jbonofre/karaf-boot
[6] http://blog.nanthrax.net
[7] http://www.talend.com

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