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 Thu, 10 Sep 2015 17:33:37 GMT
Providing jpa and jta annotations for SCR would be great. I think the 
big problem with scr is that it does not have a plugin model.
So while it might be possible to add jpa / jta processing around the 
service it might be difficult to provide it in a way that it can be 
combined with other annotations
from different sources. Like e.g. security. Unfortunately Peter Kriens 
was not very open when I asked him about such a model. Do you have an 
idea how to make it work?

Another question of course would be where to put that code.
I would tend to put such code maybe in felix near the scr impl and the 
maven bundle plugin as it is quite related.

Christian

Am 10.09.2015 um 19:22 schrieb Jean-Baptiste Onofré:
> 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"
xmlns:xsi="
>>>>>>>>>>>> http://www.w3.org/2001/XMLSchema-instance"

>>>>>>>>>>>> xsi:schemaLocation="
>>>>>>>>>>>> http://maven.apache.org/POM/4.0.0
>>>>>>>>>>>> http://maven.apache.org/xsd/maven-4.0.0.xsd">
>>>>>>>>>>>>
>>>>>>>>>>>> <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
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>


Mime
View raw message